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The  primary  purpose  of  this  effort  was  to  develop  an  efficiency 
enhanced  version  of  the  JOVIAL  Automated  Verification  System  (JAVS). 

The  enhancements  provided  Include  a re-written  syntax  analyzer  component 
which  has  significantly  reduced  the  run-time  primary  memory  requirement, 
resulting  in  a system  with  a higher  throughput  characteristic.  The  new 
system  was  installed  and  acceptance  tested  on  the  RADC  H6180/GC0S 
Computer  System.  Following  acceptance  testing,  the  system  was  released 
to  Hq  SAC,  Offutt  AFB,  Nebraska. 


‘''frank  S.  LA  MONICA 


Project  Engineer 


1 


INTRODUCTION 


JAVS,  for  JOVIAL  Automated  Verification  System,  provides  measurements  of 
testing  thoroughness,  retesting  assistance,  and  automated  software  documenta- 
tion for  JOVIAL  J3  programs. 

This  report  describes  the  design,  implementation  and  testing  of  a new 
JAVS  syntax  analyzer.  Background  information  regarding  all  JAVS  contracts  is 
provided  in  this  report,  as  are  procedures  for  installing  the  complete  JAVS 
software  package. 

Familiarity  with  the  JOVIAL  language  and  with  software  verification  term- 
inology is  assumed. 

The  primary  purpose  of  this  contract  was  to  design  and  implement  a new 
JOVIAL  J3  syntax  analyzer  for  the  JOVIAL  Automated  Verification  System  (JAVS) 
with  a main  memory  requirement  of  fewer  than  60,000  words  on  the  HIS  6180. 

This  design  allowed  a number  of  former  JAVS  constraints  which  dealt  with  the 
syntax  and  semantics  of  JOVIAL  J3  programs  to  he  removed.  Several  minor  en- 
hancements were  made  to  the  control  path  analysis  in  the  course  of  designing 
the  interface  of  this  new  syntax  analyzer  with  the  rest  of  JAVS. 

This  report  contains  a brief  overview  of  JAVS  capabilities  and  background 
information  on  the  evolution  of  JAVS.  Section  2 describes  the  newly  imple- 
mented syntax  analyzer.  Section  3 contains  the  procedures  and  results  of  ac- 
ceptance testing  for  the  syntax  analyzer  and  other  software  components  which 
it  affected.  Section  4 presents  recommendations  for  additional  capabilities 
and  modifications. 

Appendix  A contains  instructions  for  installing  the  JAVS  software  at 
sites  other  than  RADC,  Griffiss  AFB,  New  York,  and  SAC  Headquarters,  Offutt 
AFB , Nebraska.  Appendices  B and  C of  this  report  contain  the  updated  pages  to 
the  JAVS  User's  Guide-*-  and  the  JAVS  Reference  Manual^.  The  changed  pages  are 
provided  in  this  report  to  ensure  their  distribution  to  holders  of  the  1976 
edition  of  the  referenced  documents  (since  they  will  not  be  reprinted  in  their 
entirety  by  the  Government  under  this  contract). 

1.1  JAVS  CAPABILITIES 

JAVS  is  a software  tool  to  be  used  during  the  testing  of  JOVIAL  J3  pro- 
grams to  aid  in  recognizing  unexercised  program  paths,  assist  in  developing 
additional  test  cases  so  as  to  improve  test  execution  coverage,  and  automati- 
cally document  the  program.  JAVS'  documentation  features  can  also  be  applied 
during  software  development  and  debugging  stages  as  long  as  complete  control 
structures  are  provided. 

Program  verification  is  based  on  analyzing  control  flow  structures,  in- 
strumenting the  program  by  inserting  software  probes  to  measure  testing  cover- 
age during  execution,  and  comprehensive  reports  which  pinpoint  unexercised 
paths  in  the  program  structure.  Retesting  guidance  is  provided  identifying 
program  paths  leading  to  untested  program  areas  and  by  reports  describing  mod- 
ule and  symbol  interaction. 
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As  a testing  tool,  JAVS  provides  coverage  and  trace  reports  showing  pro- 
gram behavior  during  a test.  Test  performance  coverage  reports  showing 
statements  and/or  decision  outways  (conditional  branches)  can  be  obtained  on 
a per-module,  per-test-case,  and  per-test-run  basis.  These  reports  allow  the 
user  to  focus  on  untested  modules,  program  paths,  and  statements.  Tracing  can 
be  performed,  at  user  option,  to  show  module  invocations  and  returns  or  to 
show  which  outway  was  taken  for  each  conditional  operation  in  the  program.  In 
addition,  the  user  can  trace  "important"  events,  such  as  overlay  link  loading, 
by  Invoking  one  of  the  JAVS  data  collection  routines. 

If  the  testing  target  is  determined  to  be  a set  of  modules  which  received 
little  or  no  coverage  during  the  test  execution,  JAVS  reports  can  be  obtained 
to  list  all  Invocations  (and  the  statement  numbers  of  the  calls)  to  the  mod- 
ules and  to  show  the  modules'  interactions  with  the  rest  of  the  system  in 
terms  of  calling  trees  and  Interaction  matrices.  If  the  testing  target  is  a 
segment  of  code  within  a module,  the  user  can  request  a JAVS  report  showing 
the  statements  that  lead  up  to  the  target.  Armed  with  this  "reaching  set"  re- 
port, the  user  can  spot  key  variables  whose  values  affect  the  flow  through  the 
program  paths  and  locate  all  instances  of  the  variables  in  the  system-wide 
cross  reference. 

Retesting  may  necessitate  code  changes  in  some  of  the  modules  in  the  sys- 
tem to  remove  dead  code  or  coding  errors  found  during  the  test  analysis.  To 
facilitate  determining  all  modules  in  the  system  which  could  be  affected  by 
the  code  changes,  a JAVS  report  will  show  the  interaction  between  the  selected 
set  of  modules  and  the  rest  of  the  system. 

JAVS  uses  a data  base  to  store  information  about  the  test  program.  The 
availability  and  management  of  this  information  form  the  basis  for  a variety 
of  services  in  addition  to  the  primary  task  of  testing  assistance.  Computer 
program  documentation,  debugging  through  JAVS  computation  directives,  and  re- 
ports useful  for  code  optimization  are  the  major  side  benefits  of  JAVS. 

Computer  documentation  requirements  for  the  Air  Force  typically  specify 
flow  charts  an,j  lists  of  program  variables  and  constants.  In  the  JAVS  devel- 
opment and  implementation  contracts  these  requirements  were  replaced  by  speci- 
fying certain  JAVS  reports,  i.e.,  self-documentation.  It  was  found  that  the 
module  liscings  (enhanced  by  indentation  and  identification  of  decision 
points),  module  control  flow  pictures,  module  invocation  reports  (showing  for- 
mal and  actual  parameter  lists),  module  interdependence  reports,  and  a cross- 
reference  report  for  each  JAVS  component  are  more  meaningful  documentation  and 
are  generated  automatically  by  JAVS. 

Software  development  can  be  assisted  by  using  JAVS  to  document  and  test 
the  system  as  it  is  built.  To  aid  in  data  flow  analysis  and  checking  of  array 
sizes  and  variable  execution  values,  JAVS  offers  computation  directives.  The 
directives  are  a special  form  of  JOVIAL  comment , recognized  by  JAVS  and  ex- 
panded Into  executable  code  (using  the  JOVIAL  monitor  statement)  during  the 
instrumentation  phase.  The  user  can  check  logic  expressions  with  an  ASSERT 
directive,  check  boundaries  of  selected  variables  with  an  EXPECT  directive, 
and  turn  on  and  off  the  standard  monitor  tracing  with  TRACE  and  OFFTRACE  di- 
rectives. Code  optimization  is  aided  by  the  post-test  reports,  which  show  the 
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number  of  times  each  statement  is  executed  and  the  execution  time  spent  in  the 
modules  (in  milliseconds  of  central  processor  time).  Modules  which  are  never 
called  and  should  be  removed  are  listed  in  another  JAVS  report. 

Testing  coverage  results  indicate  what  parts  of  the  program  were  executed. 
It  is  up  to  the  user  to  determine  if  the  program's  output  is  reasonable.  One 
JAVS  post-test  analysis  report  lists  the  execution  coverage  during  the  test 
run  in  terms  of  the  percentage  of  decision  outways  taken.  A decision  outway 
(decision-to-decision  path,  or  DD-path)  is  the  set  of  statements  executed  as 
the  result  of  the  evaluation  of  a predicate  (conditional  operation) . A good 
standard  for  the  tested ness  of  a program  is  to  exercise  every  decision  outway 
at  least  once.  This  level  of  testing  is  more  rigorous  than  testing  every  pro- 
gram statement  at  least  once.  However,  it  should  be  emphasized  that  certain 
combinations  of  DD-paths  may  contain  errors  which  are  not  detected  in  merely 
executing  each  outway  one  time. 

JAVS  reads  the  user's  JOVIAL  program  as  data  and  performs  syntax,  struc- 
tural, and  instrumentation  analyses  on  the  source  code.  JAVS  communicates 
with  the  user  through  a command  language  and  utilizes  a data  base  to  store  the 
information  about  the  program.  The  user  is  provided  with  an  instrumented  file 
of  the  selected  program  modules  with  which  the  user  supplies  test  data  for 
execution.  The  execution  results  are  written  to  a file  from  which  JAVS'  post- 
test analyzer  issues  execution  tracing  and  coverage  reports. 

Six  functional  processes,  in  addition  to  execution  with  test  data,  make 
up  the  substance  of  software  validation  provided  by  JAVS.  The  organization  of 
JAVS  is  defined  by  these  six  tasks.  To  reduce  the  burden  of  the  user,  JAVS 
exists  as  an  overlay  program  at  RADC  with  a macro  command  language  supplement- 
ing a large,  versatile  standard  command  language.  Figure  1.1  shows  a block 
diagram  of  the  processes  and  the  four  macro  commands  (BUILD  LIBRARY,  PROBE, 
TEST,  and  DOCUMENT)  which  drive  the  processes.  The  processing  steps  and  their 
basic  functions  are  listed  below: 

BASIC,  Source  Text  Analysis:  Source  text  input,  lexical  analysis,  and 
initial  source  library  creation 

STRUCTURAL,  Structural  Analysis:  Structural  analysis  and  execution  path 
identification;  library  update  with  structure  and  path  information 

INSTRUMENT,  Module  Instrumentation:  Program  instrumentation  for  path 
coverage  analysis  and  program  performance  directed  by  the  user;  library 
update  with  probe  test  instrumentation 

ASSIST,  Module  Testing  Assistance  and  Segment  Analysis:  Testing  assis- 
tance for  improved  program  coverage 

DEPENDENCE,  Retesting  Guidance  and  Analysis:  Retesting  requirements  anal- 
ysis for  changed  modules 

TEST  EXECUTION:  Execution  of  instrumented  code  and  analysis  of  directed 


TEST 

EXECUTION  OF 
INSTRUMENTEO 
CODE 


TEST 

EFFECTIVENESS 

MEASUREMENT 


Figure  1.1.  JAVS  Processing  Sequences 


ANALYZER,  Test  Effectiveness  Measurement:  Detailed  analysis  of  program 
path  coverage;  execution  traces  and  summary  statistics 

The  user  must  provide  three  major  types  of  input  to  JAVS:  (1)  the  source 
code  to  be  tested,  (2)  a set  of  commands  to  direct  JAVS  processing,  and  (3) 
test  data  for  program  execution. 

1 . 2 BACKGROUND 


JAVS  was  developed  under  Air  Force  contract  F30602-73-C-0344  with  RADC  to 
engineer  workable  and  practical  first-level  solutions  to  the  task  of  automat- 
ing the  measurement  of  JOVIAL  computer  program  test  effectiveness.  Other 
tasks  to  be  included  in  the  test  tool  were  the  capabilities  of  assisting  the 
manual  process  of  test  case  design  and  selection  and  automating  certain  as- 
pects of  software  system  maintenance.  The  tool  which  result  -d  from  that  ef- 
fort in  1973-1975  was  a system  of  six  programs  which  performed  the  functional 
processes  shown  in  Fig.  1.1.  The  common  thread  between  the  programs  was  a 
database  library  which  contained  tables  of  syntactical,  semantic,  and  struc- 
tural information  describing  the  user's  JOVIAL  program.  This  system  required 
84,000  words  of  central  memory  to  execute  the  largest  program  (source  text  an- 
alysis) and  56,000  words  to  execute  the  smallest.  As  part  of  the  JAVS  accep- 
tance test,  all  of  the  JAVS  software  had  to  be  processed  by  JAVS  itself  and 
demonstrate  overall  statement  execution  coverage  of  85".. 
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The  syntax  analyzer  portion  of  the  source  text  analysis  program  was  de- 
veloped by  GRC's  subcontractor.  System  Development  Corporation  (SDC) , as  an 
extensive  modification  to  the  existing  GEN1  phase  of  the  SAM-D  ED  JOVIAL  com- 
piler for  the  UNIVAC  1108.  Although  this  syntax  analyzer  was  fast,  it  had 
the  following  disadvantages,  many  of  which  made  it  inconsistent  with  JOVIAL 
J3  constructs: 

1.  It  required  84,000  words  to  load  and  execute  in  the  JAVS  environment 
(which  is  the  same  for  all  JAVS  functional  processors)  and,  as  de- 
signed, could  not  be  overlayed. 

2.  Improper  generation  of  pointers  dealing  with  labels  defined  in  one 
module  and  called  from  another  module  (within  the  rules  of  JOVIAL  J3) . 
This  constraint  was  primarily  due  to  the  "one-pass"  analysis  per- 
formed on  the  JOVIAL  source. 

3.  Only  one  C0MP00L  could  be  analyzed  in  a single  execution  of  the  ana- 
lyzer. 

4.  Special  characters,  such  as  "<",  etc.  were  considered  illegal 

and  blanked  out,  thereby  affecting  consistency  of  the  instrumented 
code  with  the  original  source  code  (which  could  result  in  differing 
execution  output)  and  completeness  in  the  JAVS  documentation  reports. 

5.  A JOVIAL  CLOSE  subprogram  (external  CLOSE)  could  not  be  analyzed 
without  redefining  it  as  a main  program. 

6.  A single  prime  was  ignored;  thus  'LOC  and  other  primitives  were  in- 
correctly processed  without  the  prime. 

7.  A comment  could  not  be  terminated  by  a dollar  sign. 

8.  Labels  could  not  be  appended  to  BEGIN  statements  (they  were  dis- 
carded) . 

9.  Certain  keywords,  such  as  PROC,  in  comments  caused  erroneous  parsing 
of  the  text. 

10.  Nested  DEFINE  statements  would  not  be  expanded  properly. 

11.  The  same  status  variables  used  in  more  than  one  status  list  would 
produce  numerous  unnecessary  warnings. 

Subsequent  effort  was  directed  at  JAVS  under  Air  Force  Contract  F30602- 
76-C-0233  with  RADC.  The  major  tasks  were  to  convert  the  six  programs  into  a 
single  overlay  program,  add  a macro  command  language,  stress  and  evaluate  JAVS' 
performance  by  implementing  a systematic  software  test  on  a large,  complex  pro- 
gram not  written  for  Automated  Verification  System  (AVS)  testing  in  mind,  cor- 
rect any  JAVS  errors  found  during  the  effort,  and  improve  the  existing  testing 
methodology . ^ 
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The  overlay  configuration  reduced  the  main  memory  requirement  only  by 
'3,000  words  to  81,000  for  complete  JAVS  analysis  and  54,000  for  all  analyses 
except  syntax  analysis.  The  main  advantage  in  the  overlay  structure  was  the 
ability  to  incorporate  a simple  command  language  using  four  command  keywords: 
BUI1.D  LIBRARY,  DOCUMENT,  PROBE,  and  TEST  to  perform  most  of  JAVS'  activities. 

The  JAVS  "stress  and  evaluate"  activity  provided  much-needed  experience 
in  attempting  to  determine  the  value  of  a path-testing  AVS . The  fact  that 
JAVS  underwent  systematic  functional  and  path  coverage  testing  and  subse- 
quently was  used  extensively  to  analyze  "real  world"  unstructured  JOVIAL 
source  code  permitted  evaluation  of  the  utility  of  program  path  testing  using 
functional  data. 

The  outcome  of  this  evaluation  was  that  of  the  over  28,000  statements 
(366  modules)  comprising  the  JAVS  source,  ten  errors  were  found  after  its  de- 
livery. These  errors  fell  into  three  major  categories:  structural,  design, 
and  logic.  Of  the  structural  errors  (there  were  three),  one  was  detected  dur- 
ing the  coverage  self-test,  but  the  code  was  not  corrected  before  delivery; 
another  structural  error  manifested  itself  in  the  output  (i.e.,  the  output  was 
incorrect),  but  the  output  was  not  detected  as  erroneous;  the  third  was  simply 
one  of  the  untested  paths.  More  thorough  path  testing  would  have  uncovered 
this  infinite  loop  error. 

The  remaining  seven  errors  probably  would  not  have  been  detected  by  using 
JAVS'  path-testing  capability.  Judicious  use  of  JAVS  computation  directives 
(especially  ASSERT  and  EXPECT)  may  have  detected  the  three  logic  errors.  The 
design  errors  were  primarily  in  the  syntax  analyzer,  and  reconfirmed  the  wide- 
ly held  belief  that  extra  emphasis  should  always  be  placed  on  the  design  phase 
of  software  development  and  that  functional  test  data  should  be  designed  from 
the  specifications  concurrently  with  the  design  of  the  software. 

One  of  the  documents  delivered  under  contract  F30602-76-C-0233  was  the 
Methodology  Report.^1  The  section  of  that  document  entitled  "Application  of 
Systematic  Testing  Methodology"  addresses  the  role  of  an  AVS  (JAVS  in  particu- 
lar) in  applying  the  formally  defined  general  testing  methodology  and  provides 
practical  techniques  for  particular  situations.  The  JAVS  evaluation  experi- 
ence provided  additional  insight  into  the  design  of  the  new  syntax  analyzer, 
not  only  in  terms  of  better  understanding  of  the  language  specification,  but 
also  in  terms  of  designing  AVS-testable  software.  The  description  and  results 
of  acceptance  testing  for  the  new  syntax  analyzer  are  given  in  Sec.  3. 

1.3  OBJECTIVES  OF  THE  CURRENT  CONTRACT 

The  above  background  information  sets  the  stage  for  describing  the  objec- 
tives of  the  current  contract.  As  previously  stated,  the  primary  objective 
was  to  design  a new  syntax  analyzer  which  had  a smaller  appetite  for  central 
memory.  Other  important  considerations,  some  of  which  had  a bearing  on  the 
design,  were: 

• Eliminate  many  of  the  JAVS-imposed  restrictions  on  JOVIAL  source 

• Report  possible  structural  infinite  loops  and  dead  code 
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• Store  comments  differently  so  as  to  improve  certain  JAVS  reports 

• Include  loop  control  variables  in  the  symbol  cross  reference 

• Remove  the  incorrect  generation  of  control  cards  ($  in  column  1 on 
Honeywell  equipment)  in  the  instrumented  source  code. 

• Allow  comments  to  be  imbedded  anywhere  within  statements  or  between 
statements 

• Permit  direct  analysis  of  the  executable  source  text  (i.e.,  without 
the  user's  insertion  of  JAVSTEXT  header  statements  between  START- 
TERM  sequences,  although  this  practice  is  still  recommended) 

• Construct  the  syntax  analyzer  to  be  easily  modified  and  maintained 
1.4  JAVS  TECHNICAL  REPORTS 

The  following  list  of  documents  describe  the  current  software  for  JAVS, 
its  utilization  and  recommended  testing  methodology. 

• JAVS  Technical  Report:  Vol.  1,  User’s  Guide.  This  report  is  an  in- 
troduction to  using  JAVS  in  the  testing  process.  Its  primary  pur- 
pose is  to  acquaint  the  user  with  the  innate  potential  of  JAVS  to 
aid  in  the  program  testing  process  so  that  an  efficient  approach  to 
program  verification  can  be  undertaken.  Only  the  basic  principles 
by  which  JAVS  provides  this  assistance  are  discussed.  These  give 
the  user  a level  of  understanding  necessary  to  see  the  utility  of 
the  system.  The  material  on  JAVS  processing  in  the  report  is  pre- 
sented in  the  order  normally  followed  by  the  beginning  JAVS  user. 
Adequate  testing  can  be  achieved  using  JAVS  macro  commands  and  the 
job  streams  presented  in  this  guide.  The  Appendices  include  a sum- 
mary of  all  JAVS  commands  and  a description  of  JAVS  operation  at 
RADC  with  both  sample  command  sets  and  sample  job  control  state- 
ments. (General  Research  Corporation  CR-1-722,  November  1976; 
available  as  RADC-TR-77-126,  Vol.  I;  updated  as  General  Research 
Corporation  CR-1-722/1,  June  1978.  Updated  pages  available  in  Ap- 
pendix B of  this  report.) 

• JAVS  Technical  Report:  Vol.  2,  Reference  Manual.  This  report  de- 
scribes in  detail  JAVS  processing  and  each  of  the  JAVS  commands. 

The  Reference  Manual  is  intended  to  be  used  along  with  the  User's 
Guide  which  contains  the  machine-dependent  information  such  as  job 
control  cards  and  file  allocation.  Throughout  the  Reference  Manual, 
modules  from  a sample  JOVIAL  program  are  used  in  the  examples.  Each 
JAVS  command  is  explained  in  detail,  and  a sample  of  each  report 
produced  by  JAVS  is  included  with  the  appropriate  command.  The  re- 
port is  organized  into  two  major  parts:  one  describing  the  JAVS 
system  and  the  other  containing  the  description  of  each  JAVS  command 
in  alphabetical  order.  The  Appendices  include  a complete  listing  of 
all  error  messages  directly  produced  by  JAVS  processing.  (General 
Research  Corporation  CR-1-722,  November  1976;  available  as  RADC-TR- 
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77-12b,  Vol.  II;  updated  as  General  Research  Corporation  CK-1-772/1, 
June  1978.  Updated  pages  available  in  Appendix  C of  this  report.) 

• JAVS  Technical  Report:  Vol.  3,  Methodology  Report.  This  report  de- 
scribes the  methodology  which  underlies  and  is  supported  by  JAVS. 

The  methodology  is  tailored  to  be  largely  independent  of  implementa- 
tion and  language.  The  discussion  in  the  text  is  intended  to  be  in- 
tuitive and  demonstrative.  Some  of  the  methodology  is  based  upon 
the  experience  of  using  JAVS  to  test  a large  information  management 
system.  A long-term  growth  path  for  automated  verification  systems 
that  supports  the  methodology  is  described.  (RADC-TR-77-126,  Vol. 
Ill,  April  1977) 

• JAVS  Computer  Program  Documentation:  Vol.  1,  System  Design  and  Im- 
plementation. This  report  contains  a description  of  JAVS  software 
design,  the  organization  and  contents  of  the  JAVS  data  base,  and  a 
description  of  the  software  for  each  JAVS  component:  its  function, 
each  of  the  modules  in  the  component,  and  the  global  data  structures 
used  by  the  component.  The  report  is  intended  primarily  as  an  in- 
formal reference  for  use  in  JAVS  software  maintenance  as  a companion 
to  the  Software  Analysis  reports  described  below.  Included  in  the 
appendices  are  the  templates  for  probe  code  inserted  by  instrumenta- 
tion processing  for  both  structural  and  directive  instrumentation 
and  an  alphabetical  list  of  all  modules  in  the  system  (including 
system  routines)  with  the  formal  parameters  and  data  type  of  each 
parameter.  (GRC,  CR-1-782,  Vol.  I,  June  1978) 

• JAVS  Computer  Program  Documentation:  Vol.  2,  Software  Analysis . 

This  volume  is  a collection  of  computer  output  produced  by  JAVS 
standard  processing  steps.  The  source  for  each  component  of  the 
JAVS  software  has  been  analyzed  to  produce  enhanced  source  listings 
of  JAVS  with  indentation  and  control  structure  identification,  in- 
ter-module dependence,  all  module  invocations  with  formal  and  actual 
parameters,  module  control  structure,  a cross  reference  of  symbol 
usage,  tree  report  for  each  leading  module,  and  report  showing  size 
of  each  component.  It  is  intended  to  be  used  with  the  System  Design 
and  Implementation  Manual  for  JAVS  software  maintenance.  The  Soft- 
ware Analysis  reports,  on  file  at  RADC,  are  an  excellent  example  of 
tiie  use  of  JAVS  for  computer  software  documentation. 

• JAVS  Final  Report.  The  final  report  for  the  project  describes  the 
design,  implementation  and  testing  of  the  JAVS  syntax  analyzer. 
Background  information  regarding  all  JAVS  contracts  is  provided  as 
well  as  procedures  for  installing  the  complete  JAVS  software  package. 
This  report  contains,  as  appendices,  the  June  1978  updated  pages  for 
the  User's  Guide  and  Reference  Manual  published  as  RADG-TR-77-1 26 , 
Vols . 1 and  II,  April  1977. 
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2 JAVS  SYNTAX  ANALYZER 


The  function  of  the  syntax  analyzer  (called  JAVS2)  is  to  read  the  JOVIAL 
source  text  stream  and  generate  the  lexical  and  semantic  information  needed  by 
subsequent  phases  of  JAVS.  Each  START-TERM  sequence  is  treated  as  a separate 
unit  and  may  be  either  a COMPOOL  text  or  executable  text.  The  sequence  of 
text  characters  is  separated  into  JOVIAL  symbols,  the  symbols  are  collected 
into  statements,  and  the  statements  are  grouped  into  modules.  Symbols  are 
classified  according  to  type,  and  tables  of  identifiers  essential  to  structur- 
al analysis  are  built. 

The  source  text  presented  to  JAVS  is  assumed  to  be  free  of  syntax  er- 
rors; i.e.,  it  must  have  been  successfully  processed  by  the  JOVIAL  compiler 
without  errors.  Since  the  structural  properties  of  executable  text  are  wholly 
contained  within  the  START-TERM  sequence,  JAVS2,  unlike  the  JOVIAL  compiler, 
does  not  require  that  the  text  for  a referenced  COMPOOL  be  processed  together 
with  the  executable  text. 

The  new  JAVS2  code  uses  substantially  less  central  memory  (29,000  words), 
creates  only  that  information  about  symbols  needed  for  structural  analysis 
(with  a corresponding  savings  in  auxiliary  storage) , and  fits  into  the  overlay 
structure  of  the  remainder  of  the  JAVS  system.  The  overall  design  has  this 
JAVS  software  component  separated  into  three  distinct  processes: 

1.  An  initialization  process  which  sets  initial  data  into  JAVS2  data 
structures . 

2.  A text-recognition  process  which  reads  the  source  text,  identifies 
symbols,  statements,  and  modules,  expands  text  for  DEFINES,  con- 
structs initial  entries  in  the  permanent  tables  Module  Descriptor 
Block  (MDB),  Statement  Blocks  (SB),  and  Statement  Descriptor 
Blocks  (SDB),  and  constructs  temporary  tables  necessary  for  the 
text  analysis  process  which  follows. 

3.  An  analysis  process  which  uses  the  tables  prepared  by  the  text-rec- 
ognition processing  to  construct  the  permanent  tables  Symbol  Table 
Blocks  (STB)  and  Symbol  Locator  Blocks  (SLT)  as  well  as  final  en- 
tries in  the  MDB,  SB,  and  SDB. 

The  text-recognition  process  is  concerned  primarily  with  analyzing  the 
text  stream  for  JOVIAL  syntactical  constructs  (i.e.,  symbols,  statements,  and 
modules) ; the  analysis  process  is  concerned  with  transforming  JOVIAL  syntacti- 
cal constructs  into  the  JAVS  structural  description,  a form  which  defines  the 
basic  structural  properties  of  the  source  text. 

The  initialization  process  (1)  executes  once  for  a single  file  of  text. 
The  text  recognition  process  (2)  and  analysis  process  (3)  execute  once  for 
each  START-TERM  sequence  in  the  file  of  text.  With  this  design,  each  process 
can  be  a secondary  overlay  in  the  JAVS  system  memory  layout. 

In  implementing  this  design,  the  JAVS2  code  retains  characteristics  of 
other  JAVS  components:  it  is  highly  modular  and  well-structured,  makes  use  of 
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the  JAVS  data  manager  for  both  permanent  and  temporary  tables,  and  utilizes 
the  JAVS  nucleus  support  routines  for  basic  services.  Syntactic  units  are  to 
the  same  specifications  as  those  currently  processed  by  the  J0C1T  J0VIAL/J3 
computer,  and  the  syntax  analysis  uses  a statement  recognition  algorithm  which 
identifies  well-defined  statement  initiation  and  statement  termination  con- 
structs in  context. 

2.1  EFFECT  ON  USERS 

2.1.1  Resource  Requirements 

Execution  of  JAVS  with  the  new  syntax  analyzer  requires  53,000  words  of 
primary  memory  and  5%  less  secondary  memory  for  the  database  library.  Pro- 
cessing  time  and  file  space  estimations  are  provided  in  the  JAVS  User's  Guide 
JAVS  syntax  and  structural  analyses  require  approximately  50Z-10X  additional 
central  processor  time  than  was  required  by  the  older  version.  The  extra  CP 
time  is  primarily  due  to  using  the  JAVS  database  manager  for  information  stor- 
age and  to  the  multi-pass  design  of  the  syntax  analyzer.  One  of  the  reasons 
for  a multi-pass  syntax  analyzer  is  to  properly  handle  all  references  to  glo- 
bal labels. 

2.1.2  Constraints 

The  former  JAVS  constraints  listed  in  Sec.  1.2  have  all  been  removed. 

In  addition,  the  following  structural  rules  are  no  longer  required:  the  exe- 
cutable text  must  be  a compound  statement  (JOVIAL  makes  this  a requirement  on- 
ly for  PROCs);  a declaration  statement  with  an  END  (e.g. , an  ARRAY  or  TABLE 
declaration)  must  not  be  located  immediately  preceding  a TERM  statement. 

The  following  implementation  constraints  are  the  current  ones  which  must 
be  observed  during  source  text  processing: 

1.  Each  module  placed  on  the  same  library  must  have  a unique  module 
name  for  a given  JAVSTEXT  name.  For  this  purpose,  only  the  first 
eight  characters  of  any  name  are  used.  The  first  six  characters 
should  be  uriique  (a  compiler  restriction). 

2.  A PROC  must  contain  at  least  one  executable  statement  (e.g., 

RETURN) . 

3.  Statement  labels  in  direct  code  are  not  analyzed.  A reference  to 
such  a label  in  JOVIAL  code  is  treated  as  a reference  to  an  exter- 
nal undefined  label. 

4.  The  maximum  number  of  nested  modules  is  150. 

5.  The  maximum  number  of  unique  symbols  (names  and  constants)  is  4,096 

6.  A basic  element  may  not  exceed  500  characters  (does  not  include 
literals) . 

7.  A JOVIAL  symbol  may  not  exceed  4,095  characters. 


8.  A comment,  if  saved,  will  be  truncated  to  the  maximum  JOVIAL  symbol 
length  if  it  exceeds  that  length. 

9.  BASIC  guarantees  that  saved  comments  terminate  with  a double  prime 
(i.e.,  a double  prime  will  be  generated). 

10.  Only  the  first  72  columns  of  source  text  line  are  analyzed. 

11.  COMPOOLs  must  have  a JAVSTEXT  directive  stating  the  PRESET  type. 

12.  A statement  name  following  a TERM  (main  program  only)  will  not  de- 
termine the  first  executable  statement. 


2.1.3  Error  Messages 

The  former  syntax  analyzer  had  a repertoire  of  approximately  a hundred 
error  messages,  many  of  which  would  never  occur  if  the  user's  source  code  was 
properly  compiled.  The  complete  list  of  error  messages  emanating  from  the  new 
syntax  analyzer  are  listed  below: 


Error 

Number 

1 

2 

3 

4 

5 

6 

7 

8 
9 

10 

11 


Explanation 

Basic  element  contains  too  many  characters.  Element  truncated 
in  saved  text.  Resubmit  with  corrected  text. 

it 

Illegal  internal  text  character.  System  error. 

it 

Illegal  external  text  character.  System  error. 

Recursive  DEFINE  reference.  Reference  partially  expanded.  Re- 
submit with  recursive  DEFINE  definition  corrected. 

JOVIAL  symbol  too  long.  Symbol  truncated  in  saved  text.  Resub- 
mit with  corrected  text. 

Too  many  symbols  (names  and  constants)  in  text.  Fatal  error. 
Resubmit  with  text  partitioned  into  more  START-TERM  sequences. 

Module  nesting  exceeds  limit.  Change  module  nesting  structure. 

Too  many  ENDS.  Resubmit  with  corrected  text. 

* 

Loop  in  basic  element  analysis.  System  error. 

* 

Loop  in  internal  text  character  analysis.  System  error. 

it 

Loop  in  JOVIAL  element  analysis.  System  error. 

* 


12  Loop  in  external  character  analysis.  System  error. 


System  errors  should  be  reported  with  output  listing  card  images  processed. 
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2.1.4  Syntax  Analysis  Commands 

Several  JAVS  syntax  analysis  commands  have  been  removed.  These  are: 
BASIC,  ERRORS  - ON/OFF/LIMIT/TRACE. 

BASIC,  SYMBOLS  = ON/OFF/PART 1AL. 

BASIC,  TEXT  = PRESET/COMPUTE/BOTH/ JAVSTEXT. 


leaving  only  three  commands.  These  are: 

BASIC,  CARD  IMAGES  = ON/OFF. 

BASIC,  COMMENTS  = ON/OFF. 

BASIC,  DEFINES  = OJJ/OFF. 

where  the  default  values  are  underlined.  The  JAVS  macro  command  BUILD  LIBRARY 
specifies  the  default  values  for  syntax  analysis. 

When  the  DEFINES  option  is  ON,  JAVS  expands  the  DEFINE  references  (to 
any  level  of  nesting)  but  leaves  the  DEFINE  declaration  in  the  text.  The  for- 
mer syntax  analyzer  removed  the  DEFINE  declaration  after  expansion,  making 
documentation  ambiguous.  Compilation  of  the  instrumented  source  text  will  be 
unaffected  by  the  presence  of  the  DEFINE  and  the  expansion. 

2.1.5  JAVS  Output 

The  computer  listing  output  by  the  source  text  analysis  process  under- 
went minor  change  as  a result  of  the  new  syntax  analyzer.  The  former  output 
is  showm  in  Figs.  2.1  and  2.2.  The  message: 

<module  name''  (<JAVSTEXT  name'')  COMPLETED 

was  written  upon  completion  of  each  module's  analysis,  rather  than  at  the  end 
of  each  START -TERM  sequence. 


The  new  syntax  analyzer  performs  an  initialization  process  once,  then 
makes  two  passes  through  each  START-TERM  sequence.  One  pass  reads  the  source 
and  builds  text-recognition  tables;  the  other  pass  uses  the  tables  and  com- 
pletes the  entries.  At  the  end  of  each  START-TERM  sequence,  the  modules  in 
that  sequence  (called  TEXT)  are  listed.  Figures  2.3(a)  and  (b)  show  the  out- 
put: the  user's  card-image  input  source  with  the  card  count  printed  at  the 
rightmost  column  and  module  and  JAVSTEXT  identification  following  the  TERM 
statement . 


If  the  user  does  not  provide  the  JAVSTEXT  identification  directive  at  the 
beginning  of  each  executable  START-TERM,  JAVS  will  assign  one  using  the  last 
JAVSTEXT's  name  for  the  module ' s name  (or  JAVS0001  if  the  START-TERM  sequence 
is  the  first  one).  If  the  module  is  a PROC,  its  own  name  will  be  used.  The 
text 's  name  will  be  assigned  JAVSOOOi  where  "i"  is  the  number  of  the  module 
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Figure  2.1.  Output  from  Former  Syntax  Analyzer 
(BASIC,  CARD  IMAGES  = ON.) 
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CKCOHPL  CEXCOMPL  » COMPtfTCO 

••••••••  NO  ERRORS  WERE  FOUND  BY  JXVS-? 

CIMPLZ  (EXPROGM  > COMPLETED 

CRMPL3  tExPROGM  ) COMPtfTEO 

CXMPL1  (EXPROOM  > COMPLETED 

KRPROQm  (ExPROGm  ) completed 

••••••••  NO  ERRORS  were  FOUNO  by  JftVS-3 


Figure  2.2.  Output  from  Former  Syntax  Analyzer 
(BASIC,  CARD  IMAGES  = OFF.) 


which  is  being  processed.  Figure  2.3(b)  shows  an  example  of  the  way  JAVS  as- 
signs the  module  and  JAVSTF.XT  name,  if  they  are  not  supplied  by  the  user. 

Structural  analysis  was  enhanced  to  take  advantage  of  the  proper  global 
label  information  now  provided  by  the  new  syntax  analyzer.  Figure  2.4  shows 
the  module  statement  listing  for  module  TSTLBL.  During  structural  analysis, 
several  messages  are  printed  regarding  possible  structural  errors,  as  shown  in 
Fig.  2.5.  The  UNDEFINED  GOTO  messages  refer  to  Statements  12  and  18,  since 
LITTLE  and  ELABEL  are  ndt  defined  in  the  entire  START-TERM  sequence  [see  Fig. 
2.3(a)).  At  Statement  19,  LITTLE  is  referenced  again.  An  infinite  loop  is 
detected  starting  at  statement  23  for  the  switch  label  CLABEL.  JAVS  can  de- 
tect only  structural  infinite  loops.  Control  transfers  can  be  made  which  JAVS 
does  not  detect,  such  as  the  result  of  an  invocation,  which  modify  the  control 
flow,  thereby  making  the  infinite  loop  warning  superfluous. 

Another  program  structure  anomoly  is  reported  in  the  documentation  output 
generated  by  the  JAVS  command: 

ASSIST,  STATEMENT. 

Figure  2.6  shows  four  statements  in  module  CLOSEEX  (see  statement  listing  in 
Fig.  2.7)  which  cannot  be  executed.  The  JOVIAL  J0C1T  compiler  does  not  detect 
unreachable  code.  Details  of  these  and  all  other  JAVS  reports  are  given  in 
the  JAVS  Reference  Manual. ^ 
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THIS  PAGE  IS  BEST  QUALITY  FRACTICABIJ 
FROM  CO!Y  FUKiilSHEU  TO  LOG  ^ 


**,  JAVSTEXI  LABEL  COMPUTE  (COKPOL)" 

test 

a 

1 

" TEST  CASE  TO  TEST  LABEL  PROBLEMS  " 

test 

3 

a 

START 

TEST 

4 

3 

PP.OC  TSTLbI  (IDVIMMI)* 

TEST 

S 

4 

item  idummi  i 24  s$ 

TEST 

6 

5 

item  indx  i 2u  s$ 

TEST 

7 

6 

aaaaaaaaaaa.  begin 

TEST 

8 

7 

Indx  = -1$ 

TEST 

9 

8 

ALABEL. 

TEST 

10 

9 

indx  « indx«-i$ 

TEST 

11 

10 

goto  labej.es 

TEST 

12 

11 

goto  little* 

TEST 

13 

12 

If  indx  EQ  3$ 

TEST 

14 

13 

GOTO  CLaBELS 

TEST 

15 

14 

goto  blabels 

TEST 

1« 

15 

GOTO  SHTCK  ($INDX$)  $ 

TEST 

17 

16 

IF  INDX  EQ  5$ 

TEST 

18 

17 

GOTO  ELaBELS 

TEST 

19 

18 

SWITCH  SHTCH  - ( ALaBEL. BLABEL. LITTLE )f 

TEST 

20 

19 

LIABEL. 

TEST 

21 

20 

indx  * indx+is 

TEST 

22 

21 

close-  labele  $ 

TEST 

23 

22 

BEGIN 

test 

24 

23 

Goto  CLaBEL$ 

TEST 

25 

24 

end 

TEST 

26 

25 

goto  aLaBELS 

TEST 

27 

26 

clabel. 

TEST 

28 

27 

indx  = -i$ 

TEST 

29 

28 

GOTO  CHOICE  ( $INDX+ 1 $ ) $ 

TEST 

30 

29 

SWITCH  choice  ■ (DLABEL. BLABEL. CLABZL.DLaBEDI 

TEST 

31 

30 

dlabel. 

TEST 

32 

31 

indx  * indx+i$ 

TEST 

33 

32 

GOTO  aLaBELS 

TEST 

34 

33 

END 

TEST 

35 

34 

terms 

TEST 

36 

35 

HOdOLCS  defined  in  text 

1 TSTLBL  (LABEL  ) 

2 LABELS  (label  ) 


Figure  2.3(a).  Output  from  New  Syntax  Analyzer 
(BASIC,  CARD  IMAGES  = ON) 
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miT  $ 

TESl 

37 

1 

1 

TEST 

39 

2 

PR nC  ZILCH  « 

test 

39 

3 

ARRAY  ABCOEP  I S * 

TEST 

40 

4 

BEGIN 

TEST 

4 1 

5 

23.4.SE3A2  END 

TEST 

42 

6 

begin 

TEST 

43 

7 

X-l9 

TEST 

44 

9 

C-2* 

TEST 

45 

9 

iTEn  AAAA  I 5 1.4$ 

TEST 

46 

10 

ITEn  A A A A 1 5 1 . . 4 $ 

TEST 

47 

11 

ITEM  AAAA  I 5 1...4$ 

TEST 

49 

12 

ITEM  A A A A I 5 1....4$ 

TEST 

49 

13 

ITEM  AAAA  I 5 1 

TEST 

50 

14 

ITEF1  AAAA  I 5 194  » 

TEST 

51 

15 

ITCH  AAAA  I 5 .4$ 

test 

52 

16 

ITEn  AAAA  I 5 ..49 

TEST 

53 

17 

ITEH  AAAA  I 5 ...4$ 

TEST 

54 

18 

ITEtt  AAAA  I 5 ....4$ 

TEST 

55 

19 

ITEM  AAAA  I 5 4$ 

TEST 

56 

20 

DIRECT 

TEST 

57 

21 

ASSIGN  AN  0>  A 7 AND  AS 

TEST 

59 

22 

A ASSIGN  B 

TEST 

59 

23 

C 0 ASSIGN  E 

TEST 

60 

24 

JOVIAL 

TEST 

61 

25 

BDB-AAAS 

TEST 

62 

26 

B2B-«AAA$ 

TEST 

63 

27 

END 

TEST 

64 

28 

define  BEO  •'  begin  •'  9 

TEST 

65 

29 

BEG 

TEST 

66 

30 

end 

TEST 

67 

31 

invoke  $ Label, 

TEST 

69 

32 

FOR  I - AABB(C).DD(E).rr(0)$ 

TEST 

69 

33 

PR.iC  nANTPARAnETERS(IN.OUT.CROS3*HATCH  .AGAZE. )» 

TEST 

70 

34 

begin 

TEST 

71 

35 

A»3$ 

TEST 

72 

36 

END 

TEST 

73 

37 

TERM 

TEST 

74 

36 

NODULES  DEPINED  IN  TEXT 

3 LABEL  (JAVS0003) 

* SILCH  (JAVS0003) 
f nAETPABA(JAVSo0O3) 

Figure  2.3(b).  Output  from  the  New  Syntax  Analyzer 
(BASIC,  CARD  IMAGES  - ON.) 
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Figure  2.4.  Module  Statement  Listing  for  TSTLBL 


••••  mol 


u*DErx»ro  soto, 


STATEMENT  DEScSIPTJ*  BLOCXS  UPDATED. 

HODOII  NaHE  • TSHgL  . EXTE*U»I.  EABEl  ■ UITU  at  STATEMENT  NtJ«BEA  - 19, 

INI  rOilO«I»G  STATEMENTS  CONSTITUTE  a POSSIBLE  inmnite  LOOT  , . , 

2J  24  22  23 


••••  mol  •••• 


POSSIBLE  iSriNlTI  loop  detected. 


Figure  2.5.  Structural  Analysis  Output  for  TSTLBL 


statement/ ddfath  listing 

BOdUII  <closeex  >.  JaVSIEXT  <EXTEHKAL>.  PARENT  module  <extebnal> 


dd-paths  begun 

BY  STATEMENT 


DD-PaTHS  CONTAINING  STATEMENT 


*•*  POTENTIALLY  unreachable  statement  •** 

potentially  UNREACHABLE  statement  *** 

( 4-  S)  3E  4B  5B 

5 

5 

potentially  unreachable  statement  *** 

***  potentially  unreachable  statement  *•« 


Figure  2.6.  Executable  Statements  Contained  on 
Each  Decision-to-Decision  Path 
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RODUi*  STATEMENT  LISTING 

KOOULE  <CLOSEEX  >.  JuVSTEXT  <EXTERNAL>.  PARENT  MODULE  <EXTEBNAL> 

NO.  LVL  STATEMENT  DO-PATHS 


1 

( 

0) 

CLOSE  CLOSEEX  S 

2 

( 

1) 

BEGIN 

3 

< 

1) 

AP  - 1 $ 

it 

( 

1) 

tor  j = 2 $ 

5 

l 

2) 

pohlab. 

6 

{ 

2) 

begin 

7 

{ 

2) 

tor  k - i . io  $ 

S 

{ 

3) 

BEGIN 

9 

( 

3) 

TOR  I - 1 , 1 . 3 * 

10 

( 

9) 

BEGIN 

11 

( 

4) 

IT  REAL  LQ  0.0  $ 

12 

( 

5) 

TEST  I S 

13 

( 

4) 

GOTO  rORLAB  $ 

lit 

( 

4) 

REAL  « I S 

15 

t 

4) 

I - 4 S 

16 

t 

4) 

END 

17 

( 

3) 

REAL  - * ABS  ( J ) 

18 

( 

3) 

END 

19 

( 

2) 

END 

20 

( 

1) 

END 

Figure  2.7.  Module  Statement  Listing  for  CLOSEEX 

I 

2.2  DESIGN  OF  THE  SYNTAX  ANALYZER 

The  Syntax  Analysis  component  (known  as  JAVS-2)  reads  JOVIAL/J3  source 
text  and  creates  the  MDB,  SDB,  SB,  SLT,  and  STB  tables  for  each  module  in  the 
input  file.  The  input  file  contains  one  or  more  START-TERM  texts;  each  of 
which  may  be  either  a COMPOOL  text  or  program  text.  The  type  of  text  is  de- 
clared in  the  JAVSTEXT  directive  used  to  identify  the  text;  this  directive  must 
appear  at  the  beginning  of  the  START-TERM  text  of  a COMPOOL  and  should  be  pres- 
ent for  executable  START-TERM  texts  as  well.  Each  text  is  processed  as  a sep- 
arate unit  and  no  specific  relationships  between  units  (i.e.,  a program  text 
referencing  names  declared  in  a COMPOOL  text)  are  assumed  or  identified. 

JAVS-2  produces  three  major  classes  of  information: 

1.  The  Module  Descriptor  Block  (MDB) 

2.  The  Statement  Block  (SB)  and  Statement  Descriptor  Block  (SDB) 
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3. 


The  Symbol  Locator  Table  (SLT)  and  the  Symbol  Table  Block  (STB) 


VI 

1-1 


The  JAVS-2  processor  is  organized  into  three  distinct  processes: 

1.  An  initialization  process  (FINIT)  which  sets  initial  data  into 
JAVS-2  data  structures.  This  process  is  executed  once  for  the  in- 
put file. 

2.  A text  recognition  process  (FONE)  which  reads  the  source  text,  cap- 
tures DEFINE  declarations,  expands  the  text  for  references  to 
DEFINE,  identifies  JOVIAL  symbols,  statements,  and  modules,  creates 
entries  in  the  permanent  tables  MDB,  SDB,  and  SB,  and  constructs 
other  temporary  tables  necessary  for  the  text  analysis  process 
which  follows.  This  process  is  executed  once  for  each  START-TERM 
text  in  the  input  file. 

3.  An  analysis  process  (FTWO)  which  uses  the  tables  prepared  by  the 
text-recognition  process  to  construct  the  permanent  tables  SLT  and 
STB  and  to  complete  related  entries  in  the  MDB,  SDB  and  SB.  This 
process  is  executed  once  for  each  START-TERM  text  in  the  input  file. 

The  initialization  process  (1)  defines  values  for  entries  in  key  items 
and  arrays  which  describe  the  J0V1AL/J3  language  elements  (e.g.,  character  set, 
primitives,  ideograms)  and  JAVS  descriptive  elements  (e.g.,  statement  types 
and  token  types).  Since  many  of  these  values  are  interrelated,  initialization 
is  better  done  by  executing  code  rather  than  by  using  preset  values.  This  al- 
so permits  machine  dependencies  to  be  isolated  within  a set  of  DEFINES  con- 
tained in  all  JAVS-2  compilation  units. 

The  text  recognition  process  (2)  is  concerned  primarily  with  analyzing 
the  source  text  stream  for  elementary  JOVIAL  syntactical  constructs  (i.e., 
JOVIAL  symbols,  statements,  and  modules)  and  recording  the  syntactic  descrip- 
tion in  the  JAVS  data  base. 

The  analysis  process  (3)  is  concerned  with  transforming  JOVIAL  syntacti- 
cal constructs  which  pertain  to  program  flow,  or  control,  into  the  JAVS  struc- 
tural description,  a form  which  defines  the  basic  structural  properties  of  the 
source  text.  Since  JAVS  has  no  capability  for  data  flow  analysis,  the  result- 
ing data  base  description  contains  only  control  symbols  (i.e.,  modules,  labels, 
and  switches)  and  does  not  contain  other  symbols  such  as  items,  tables,  and 
arrays . 

The  modules  of  JAVS-2  are  hierarchically  arranged.  At  the  highest  level, 
STEP1  sets  BASIC  default  options,  interprets  each  BASIC  command  for  user-speci- 
fied options,  and  invokes  JAVS2  to  process  a source  file.  JAVS2  processes  the 
options  and  invokes  the  lower-level  driver  FRONTKND.  FRONTEND  first  calls 
FINIT,  then  alternately  Invokes  FONE  and  FTWO  for  each  START-TERM  text  until 
an  end-of-file  is  encountered.  At  the  lowest  level,  FINIT  and  FONE  both  in- 
voke modules  which  clear  core-resident  work  areas  (e.g.,  AZAP,  BZAP,  etc.), 
and  all  three  major  processors  invoke  modules  (MGET  and  MPUT)  to  fetch  and 
store  the  MDB  entry.  In  its  overlay  form,  the  primary  link  for  the  component 
(JAVS-2A)  should  consist  of  STEP1,  JAVS2,  FRONTEND  and  the  low-level  modules. 
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Secondary  links  are  (1)  JAVS2-B,  other  modules  executed  with  FINIT  (e.g., 

INIT,  etc.),  (2)  JAVS2-C,  other  modules  executed  with  FONE  (e.g.,  SGET,  etc.), 
and  (3)  JAVS2-D,  other  modules  executed  with  FTWO  (e.g.,  SYMDEF  and  SYMREF, 
etc.).  The  memory  layout  in  Fig.  2.8  shows  each  JAVS-2  link  along  with  the 
remainder  of  JAVS. 

2.2.1  JAVS2-A  (Primary  Overlay) 

In  the  hierarchy  of  modules,  the  top  is  STEP1  which  sets  processing  op- 
tions to  default  values  upon  first  execution,  interprets  each  BASIC  command 
for  user-defined  options,  and  invokes  JAVS2  for  the  BASIC  execution  command. 
JAVS2  interprets  the  designated  processing  options,  sets  flags  for  these  op- 
tions and  invokes  FRONTEND.  FRONTEND  drives  all  JAVS-2  processing  for  an  In- 
put source  text  file.  After  an  initializing  call  to  FINIT,  FONE  and  FTWO  are 
called  for  each  START-TERM  sequence  until  an  end-of-file  is  encountered  on  the 
input  file.  The  remainder  of  JAVS2-A  consists  of  "zap"  routines  which  clear 
the  various  workspaces  and  modules  to  handle  table  structures  (MGET  and  MPUT) . 

2.2.2  JAVS-2B  Initialization  Process  Modules  (Secondary  Overlay) 

FINIT  drives  initialization  processing  for  one  input  file.  It  presets 
initial  module  values  and  invokes  INIT  to  initialize  values  used  for  internal 
processing  of  J0VIAL/J3  language  texts.  The  remainder  of  JAVS2-B  consists  of 
the  initialization  modules  called  by  INIT. 

2.2.3  JAVS-2C  Text  Recognition  Process  Modules  (Secondary  Overlay) 

FONE  drives  text  recognition  processing  for  one  START-TERM  text.  It  be- 
gins by  invoking  STZAP  and  JGF.T  for  the  first  JOVIAL  symbol.  If  there  is  not 
an  end-of-file  encountered  at  the  first  symbol,  then  it  invokes  MODZAP  to  cre- 
ate the  first  module  and  LPUSH  to  put  the  module  on  the  module  nesting  stack. 
Thereafter  it  invokes  SGET  for  each  statement  in  the  START-TERM  sequence  until 
the  module  stack  is  empty  (a  condition  signifying  the  end-of-file  or  a TERM 
statement) . 

2.2.4  JAVS-2D  Analysis  Process  Modules  (Secondary  Overl a\0 

FTWO  drives  analysis  processing  for  one  START-TERM  text.  The  objective 
of  the  analysis  process  is  to  construct  the  SLT  and  STB  entries  for  control 
symbols  (i.e.,  module  names,  statement  labels,  and  switch  names)  defined  or 
referenced  in  the  text  and  to  place  SLT  pointers  for  these  symbols  in  the  SB 
entries.  At  the  conclusion  of  FONE,  the  SB  contains  the  hash  index  for  all 
names  and  constants;  the  hash  index  is  used  to  access  the  appropriate  entry  In 
the  temporary  spelling  table.  FTWO  replaces  the  hash  index  in  the  SB  by  the 
appropriate  SLT  index  for  control  symbols,  by  the  token  descriptor  NAME  for 
any  other  name,  or  by  the  token  descriptor  CNST  for  a constant. 

Specialized  algorithms  are  used  to  scan  the  SB  for  control  symbols  only. 
These  algorithms  permit  scanning  to  terminate  as  soon  as  possible  in  each 
statement  scanned,  and  only  statements  of  types  which  are  permitted  to  contain 
control  symbols  are  scanned.  The  analysis  algorithms  permit  processing  to  be 
further  divided  into  two  sub-processes:  one  for  symbol  declaration  and  one 
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Figure  2.8.  JAVS  Memory  Layout 
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for  symbol  reference.  All  modules  for  a single  START-TERM  are  first  processed 
for  control  symbol  declaration;  the  same  modules  are  then  processed  for  con- 
trol symbol  references.  Undeclared  control  symbols  are  treated  as  external 
(to  the  START-TERM  text)  undefined  symbols  which  are  assumed  to  be  declared  in 
a COMPOOL.  This  eliminates  the  need  for  processing  a referenced  COMPOOL. 

FTWO  contains  two  successive  loops,  each  of  which  selects  the  modules  in 
the  order  encountered  in  the  original  source  text.  The  first  loop  invokes 
SYMDEF  to  capture  the  declared  control  symbols  for  a particular  module.  The 
second  loop  invokes  SYMREF  to  resolve  references  to  control  symbols  and  cap- 
ture any  undeclared  control  symbols  referenced  by  the  modules.  SYMDEF  and 
SYMREF  process  all  the  entries  in  the  SB  for  the  designated  module.  FTWO  con- 
trols substitution  of  the  hash  index  in  the  SB  by  the  SLT  index  through  a pro- 
cessing flag  FLTOKEN  which  is  set  FALSE  for  the  first  loop  and  TRUE  for  the 
second. 

Scope  of  declaration  and  reference  is  handled  by  module  nesting  informa- 
tion captured  in  the  MDB  during  FONE  processing.  This  information  is  added  to 
the  spelling  table  together  with  a symbol  category  when  a symbol  is  declared. 
If  more  than  one  control  symbol  is  declared  for  a particular  spelling  entry,  a 
new  spelling  entry  is  made  and  linked  to  the  original  entry.  When  a reference 
to  a control  symbol  is  encountered,  the  information  in  the  spelling  table 
(which  is  now  a symbol  table)  is  used  to  resolve  the  reference  according  to 
symbol  category,  scope  of  reference,  and  scope  of  declaration. 

2.2.5  JAVS2  Data  Structures 


The  data  structures  in  JAVS-2  are  organized  into  a number  of  categories: 

• DEFINE  declarations  which  establish  dimensions,  types,  and  machine 
dependencies 

• Text  buffers  and  descriptive  data  for  text  elements 

• Processing  flags  to  control  analysis 

• Error  indicators  and  loop  counts 

• Temporary  variables 

• Tables  managed  by  the  Data  Management  Component 

• JAVSTEXT,  Module,  and  statement  information 

• Symbol  dictionary,  including  a hash  table  and  spelling  table 

All  declarations  appear  in  the  JAVS-2  COMPOOL  except  for  local  temporary  vari- 
ables. There  are  no  preset  values  in  the  COMPOOL;  instead,  each  constant  used 
in  processing  is  declared  in  a DEFINE  or  is  set  during  execution  of  FINIT. 


2 . 2 . b JAVS-2  Text  Buffers  ami  Descr ipt ive  Data 

Source  text  being  processed  by  JAVS-2  moves  through  a series  of  buffers 
or  workspaces  In  the  course  of  transforming  card  1 lues  to  JAVS  statement 
blocks.  An  overview  of  this  process  is  shown  in  Fig.  2.9. 

GTCARD  reads  the  source  text  a card  line  at  a time  from  the  input  file, 
places  it  in  the  input  line  workspace  IS,  and  sets  the  number  of  characters  in 
IL.  The  input  line  pointer  IT  is  initialized  to  the  first  character  in  IS  and 
is  incremented  as  each  character  is  drawn  from  IS  by  TGET.  Whenever  the  line 
is  exhausted,  TGET  invokes  GTCARD  for  the  next  line.  If  the  end-of-file  is 
encountered  by  GTCARD,  IL  is  set  to  a large  default  value  (e.g.,  81). 

TGET  always  moves  the  current  input  character  into  the  external  input 
text  workspace  TS . If  DIRECT  code  is  being  processed,  each  new  line  is  moved 
directly  to  the  JAVS  Statement  Block.  The  type  of  input  text  character  is  set 
to  one  of  the  following:  TT EMPTY , TTCHAR,  TTENDFILE,  or  TTENDLINE. 

CGET  interprets  the  input  character  in  TS  and  converts  it  to  an  internal 
JOVIAL  sign  CS . The  type  of  internal  JOVIAL  sign  is  set  to  one  of  the  follow- 
ing: CTEMPTY,  CTBLANK,  CTLETTER,  CTNUMKRAL , CTSPECIAL,  or  CTOTHER . End-of- 
l ine  and  end-of-file  characters  are  included  in  the  set  of  permitted  values 
for  CS. 


CBMOVF-  adds  a character  from  CS  into  the  basic  JOVIAL  element  workspace 
BS  as  directed  by  BGET.  BGET  also  assigns  the  type  of  basic  element  BT  to  one 
of  the  following:  BTKMPTY , BTALPHABET I C , BTALPHANUMERIC,  BTASIS,  BT IDEOGRAM, 
BTNUMBER,  BTSPACE,  BTTEXTBREAK,  and  BTUNKNOWN . If  JOVIAL  text  is  being  pro- 
cessed, BGET  ignores  end-of-line  characters;  if  DIRECT  text  is  being  processed, 
BGET  recognizes  end-of-line  as  a basic  element. 

BJMOVE  adds  a basic  JOVIAL  element  from  BS  to  the  JOVIAL  symbol  JS.  A 
JOVIAL  symbol  consists  of  one  or  more  basic  elements.  When  processing  a com- 
ment or  a string  of  characters  in  a textual  literal,  CJMOVE  adds  each  charac- 
ter to  JS  from  CS,  bypassing  the  use  of  BS.  JGETSYM  and  JGETCOM  control  the 
construction  of  JS.  The  type  of  symbol  JT  is  also  set. 

Text  from  JS  is  added  to  the  JAVS  Statement  Block  workspace  by  JSMDVE 
and  from  there  it  ultimately  goes  Into  the  data  base.  While  processing  a 
DEFINE  declaration,  text  from  JS  is  added  to  the  DEFINE  descriptor  workspace 
DS  by  JAMOVE.  Symbols  of  type  JTNAME  and  JTCONSTANT  are  also  entered  into  the 
spelling  workspace  SS  by  JSAVF.. 

When  expanding  a DEFINE  reference  AGF.T  replaces  the  referenced  DEFINE 
name  in  JS  by  the  sequence  of  symbols  previously  saved  in  DS.  Nested  DEFINE 
references  are  permitted,  although  recursion  is  not  allowed. 
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Figure  2.9.  Flow  of  Text  Data 
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ACCEPTANCE  TESTING 


Formal  acceptance  testing  had  three  distinct  phases:  a functional  test, 
several  operational  software  tests,  and  path  coverage  tests.  Prior  to  instal- 
lation of  the  new  syntax  analyzer  and  t lie  other  modified  components  at  RADC, 
the  JAVS-2  component  underwent  extensive  debugging  tests. 

JAVS-2  was  developed  at  GRC  in  Santa  Barbara  using  the  CDC  J0V1A1.  .13 
compiler.  When  each  of  the  two  processors  [text  recognition  (.1AVS2-C)  and 
analysis  (JAVS2-D) 1 were  designed  and  coded,  they  were  executed  with  large 
quantities  of  JOVIAL  compiler-validation  code.  First,  JAVS2-C  was  interfaced 
with  the  syntax  analysis  driver  and  JAVS  utility  and  data  manager  components. 
This  subset  of  the  syntax  analyzer  was  then  tested  for  its  proper  functions, 
such  as  breaking  START-TERM  sequences  into  modules,  identifying  JOVIAL  symbols 
and  statements , expanding  DEFINES,  etc.  Output  for  this  process  came  from 
JAVS's  capability  of  printing  all  internal  permanent  tables. 

After  JAVS-2C  performed  all  its  functions  properly,  JAVS-2D  was  designed, 
coded,  added  to  syntax  analyzer  subset,  and  tested  the  same  way.  Following 
proper  performance  of  botli  processors,  interface  and  testing  with  the  other 
JAVS  functional  components  was  performed.  Isolating  and  testing  the  software 
in  this  manner  provided  speedy  detection  of  errors.  The  operational  version 
of  JAVS  was  used  to  obtain  indented  module  listings  and  symbol  cross  refer- 
ences as  an  aid  in  implementing  the  new  version  of  the  syntax  analyzer. 

A source  input  file  was  created  which  contained  all  JOVIAL  J3  module 
types,  statements,  control  constructs  and  JAVS  directives  for  usage  as  the 
test  object  for  the  functional  and  path  coverage  tests.  The  functional  test 
was  performed  on  the  CDC  6400  to  be  used  as  the  standard  for  the  test  on  the 
HIS  6180. 

Transfer  of  the  syntax  analyzer  and  other  modified  components  (structur- 
al, instrumentation,  and  retesting  assistance)  to  the  HIS  6180  which  uses  the 
JOVIAL  JOCIT  compiler  required  about  30  source  line  changes,  some  of  which 
were  machine  dependencies  (e.g.,  word  size  in  bits  and  characters). 

3.1  FUNCTIONAL  TEST 

The  purpose  of  the  functional  test  was  to  demonstrate  correct  processing 
of  all  JOVIAL  J3  constructs,  verify  the  reduced  primary  memory  requirement, 
and  demonstrate  all  enhanced  JAVS  features. 

For  a variety  of  reasons,  the  new  syntax  analyzer  was  designed  to  per- 
form a few  operations  differently  than  the  former  syntax  analyzer.  Some  of 
these  operations  are:  (1)  store  only  control  symbols  in  the  Symbol  Locator 
Table  (SLT),  (2)  parse  labels  on  BEGIN  and  END  statements  as  separate  state- 
ments of  type  NULL,  (3)  do  not  distinguish  (as  far  as  statement  type  is  con- 
cerned) between  an  item  and  a table  item,  (4)  parse  comments  as  a single  token, 
(5)  collect  all  comments  which  follow  a JOVIAL  statement  (i.e.,  follow  a $1 
other  than  a BEGIN  or  END  and  store  them  as  part  of  that  statement,  (6)  store 
a comment  which  follows  a BEGIN  or  END  as  a separate  statement  of  type  COM!. 

In  addition  to  these  differences,  the  new  syntax  analyzer  removed  all  ot  tin- 
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former  restrictions  listed  in  Sec.  1.2.  Thus  each  of  these  specific  design 
changes  were  considered  as  areas  for  stress  testing. 


In  order  to  demonstrate  functional  correctness  with  a minimal  amount  of 
computer  resources  and  printout,  these  procedures  were  followed: 

1.  Develop  test  object 

Include  at  least  one  of  each  type  of  JOVIAL  construct  with  the 
least  amount  of  duplication  of  types. 

Include  constructs  that  would  invoke  JAVS  error  processing  but  not 
cause  a fatal  error. 

Include  JAVS  computation  directives  to  ensure  proper  parsing  of 
these  constructs 

2.  Generate  JAVS  Command  Set 

Print  syntax  and  structural  tables  following  syntax  and  structural 
analyses 

Perform  full  instrumentation  to  demonstrate  proper  expansion  of 
JAVS  computation  directives  as  well  as  structural  instrumentation. 

Include  commands  which  would  invoke  each  JAVS  overlay  load  module. 

Use  a mixture  of  macro  and  standard  commands. 

3.  Execute  the  testing  using  the  job  control  card  setup  provided  in 
the  JAVS  User's  Guide^ 

4.  Analyze  the  output 

Verify  all  JOVIAL  J3  module,  statement,  and  control  symbol  types 

- Verify  correct  generation  of  DD-paths 
Verify  all  generated  JAVS  error  messages 

- Verify  proper  instrumentation 

Verify  correct  execution  of  all  enhancements 

- Verify  reduced  primary  core  requirements 

The  test  object  consisted  of  approximately  600  JOVIAL  source  lines.  The 
JAVS  report  (which  concludes  all  JAVS  execution  runs)  in  Fig.  3.1  summarizes 
some  of  the  characteristics  of  the  test  object.  The  JAVS  command  sequence, 
after  expansion  into  standard  commands,  is  shown  in  Fig.  3.2. 
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END. 


Figure  3.2.  JAVS  Commands  for  Functional  Test 
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The  report  in  Fig.  3.1  was  used  to  verify  recognition  of  all  module 
types . Statement  type  recognition  was  verified  by  analyzing  the  "STMT  CLASS" 
and  "TYPE  CODE"  columns  of  the  table  printed  in  Fig.  3.3  for  several  modules 
in  the  test  object.  Verification  of  control  symbol  recognition  was  performed 
by  analyzing  SLT  and  STB  tables  for  several  modules  in  the  test  object,  such 
as  those  in  Figs.  3.4(a)  and  (b) . 

DD-path  generation  was  demonstrated  by  printing  the  DD-path  table  and 
definition  reports,  shown  in  Figs.  3.5(a)  and  (b) , for  several  modules. 

Reduced  core  requirement  was  evident  on  the  computer  dayfile  for  the 
functional  test.  Proper  instrumentation  and  implementation  of  enhancements 
was  demonstrated  by  analyzing  JAVS  reports  produced  by  the  functional  test 
run.  Comparison  of  execution  time  and  secondary  storage  requirements  between 
JAVS  with  the  new  syntax  analyzer  and  the  former  one  was  not  possible  in  this 
particular  functional  test,  since  the  test  object  quickly  produced  a fatal  er- 
ror when  the  attempt  was  made  to  run  with  the  former  version  of  JAVS. 

Two  errors  stemming  from  the  syntax  analyzer  were  uncovered  during  the 
functional  test.  One  error  was  the  improper  number  of  elements  being  initial- 
ized in  an  array.  This  would  have  been  detected  during  debugging,  except  that 
debugging  took  place  using  the  non-overlay  version  of  JAVS  on  the  CDC  6400. 

The  extra  elements  being  initialized  were  harmlessly  resident  in  unused  core. 
The  other  error  was  caused  by  correct  module  classification  for  functions  as 
type  "FUNC."  The  former  syntax  analyzer  classified  functions  as  "PROC." 

Thus,  during  structural  analysis,  modules  of  type  FUNC  were  not  recognized. 

This  was  not  detected  before  transfer  to  RADC  because  a function  example  had 
not  been  included  in  the  test  objecc.  These  errors  required  only  five  source 
line  changes  in  the  syntax  and  structural  analyzers.  The  functional  test  was 
repeated  on  the  corrected  JAVS  execute  (*H)  file. 

3.2  OPERATIONAL  TESTS 

The  operational  tests  took  the  form  of  running  a small  computational 
program  (used  by  RADC  for  installation  checkout) , JAVS  self-documentation 
runs,  and  analysis  of  "foreign"  JOVIAL  code  supplied  by  RADC. 

The  operational  program's  analysis  helped  provide  data  to  compare  com- 
puter resource  differences  between  the  former  and  new  versions  of  JAVS  and 
verify  that  the  functional  performance  was  the  same. 

JAVS  documentation  runs  were  made  for  each  modified  JAVS  software  com- 
ponent. These  components  were:  the  syntax  analyzer  (JAVS-2) , structural  anal- 
yzer (JAVS-3,-4) , instrumentor  (JAVS-5) , and  retesting  assistant  (JAVS-7) . 

Each  documentation  run  produced  the  listings  specified  for  computer  documenta- 
tion in  the  Statement  of  Work.  This  and  the  self-documentation  runs  generated 
under  the  previous  contract,  together  with  the  System  Design  and  Implementa- 
t ion  Manual , ^ make  up  the  complete  computer  program  documentation  for  JAVS. 
These  runs  provided  additional  data  for  comparing  computer  resources  between 
the  former  and  new  versions. 
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Figure  3.3.  Statement  Description 
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Figure  3.4.  Control  Symbol  Description 


DD-path  generation  was  demonstrated  by  printing  the  DD-path  table 
and  definition  reports,  shown  in  Figs.  3.5(a)  and  (b),  for  several  modules 
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Figure  3.5.  DD-path  Information 
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Additional  operat  ional  tests  were  made  on  JOVIAL  source  supplied  by 
RADC.  In  these  tests,  the  test  objects  were  subsets  of  programs.  The  test 
object;;  were  processed  through  Instrumentation  and  the  instrumented  files 
passed  t o tin'  JOG  IT  compiler.  At  this  stage,  instrumentation  errors  became 
evident.  The  errors  were  due  to  the  presence  of  long  tokens  (comments,  in 
this  case)  which  continued  onto  the  next  line.  The  problem  arose  only  in  IF 
statements,  where  the  instrumented  control  keyword  changes  to  an  1FEIT11. 

Along  this  same  line  of  proper  extraction  of  source,  an  error  in  building  a 
somce  line  for  indented  printing  was  detected.  both  errors  required  a very 
select  set  ol  circumstances  to  manifest  themselves.  The  new  syntax  analyzer's 
charact er  1st ic  of  parsing  a comment  as  a single  token  was  the  catalyst. 

These  errors  were  corrected,  the  operational  tests  rerun  with  no  com- 
piler errors,  and  the  modified  JAVS  component  was  redocumented  by  JAVS. 

i.  1 PATH  COVERAGE  TESTS 

The  path  coverage  goal  was  to  determine  what  parts  of  the  syntax  analy- 
zer had  not  vet  been  exercised  by  a data  set  which  should  represent  a full 
range  of  JOVIAL  syntax.  Any  control  paths  not  executed  were  to  be  analyzed. 

The  self-documentation  output  for  JAVS-2  was  reviewed  to  help  choose  the 
test  objects.  The  syntax  analyzer  (JAVS-2)  consists  of  121  modules  in  20 
START-TERM  sequences,  including  the  C0MP00L.  Many  of  these  START-TERMs  are 
low-level  routines  which  contain  only  one  to  three  DD-paths  and  are  invoked 
many  times.  The  computer  and  human  resources  required  in  analyzing  these 
routines,  the  inconvenience  of  adding  the  JOCIT-required  control  cards  to 
each  instrumented  START-TERM  sequence,  and  the  knowledge  that  the  higher  level 
JAVS-2C  and  JAVS -2 II  subcomponen  invoke  most  of  the  low-level  routines  were 
the  justifications  for  choosing  J WS2-C  and  JAVS-2D  as  test  objects. 

Figure  3.6  shows  the  overall  flow  of  activities  performed  to  obtain  path 
coverage  results  for  the  two  subcomponents.  The  first  step  in  obtaining  path 
coverage  results  was  to  build  a database  library  and  instrument  JAVS2-C.  Both 
test  objects  were  put  on  the  database  library  for  efficiency  purposes.  Each 
software  subcomponent  was  then  tested  separately  since  JAVS2-C  and  JAVS2-D  are 
functionally  distinct  and  do  not  reside  in  core  at  the  same  time. 

The  600-line  source  program  used  in  the  functional  test  was  to  be  the 
JOVIAL  program  used  as  one  of  the  two  inputs  to  the  test  execution  phase.  The 
other  input  was  the  JAVS  command  set: 

CREATE  LIBRARY  = TEST. 

START . 

BASIC. 


The  lull  source  program  required  too  much  computer  time  and  AUDIT  tile  space 
for  realistic  analysis  of  JAVS-2C.  JAVS-20  performs  syntax  analysis  at  the 


...  .c-i 
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character  and  symbol  level  and  thus  executes  slowly  in  its  instrumented  form. 
To  reduce  resource  requirements,  the  source  program  was  cut  to  200  lines, 
leaving  out  such  JOVIAL  constructs  as  item  switch,  function,  input  parameter, 
nested  DEFINE,  exponentiation,  and  octal  constant. 

JAVS  analysis  of  the  two  execution  trace  files,  generated  from  using 
the  200-line  source  program  as  data,  showed  that  an  overall  69%  of  the  1,203 
DD-paths  in  JAVS-2C  and  JAVS2-D  were  exercised.  The  overall  statement  execu- 
tion coverage  was  78%  out  of  3,055  executable  statements  (3,622  total  source 
statements) . 

During  instrumentation,  the  user  specifies  a testcase  boundary  via  a 
JAVS  command.  For  the  two  coverage  tests,  the  boundary  was  placed  in  the 
driver  modules  for  each  subcomponent.  This  caused  the  execution  of  each 
START-TERM  sequence  to  be  a separate  testcase.  Thus,  the  effects  of  specific 
JOVIAL  statement  types  could  be  analyzed  in  terms  of  what  DD-paths  were  or 
were  not  hit.  Judicious  testcase  boundary  definition  can  aid  in  the  process 
of  modifying  input  data  for  subsequent  testing. 

The  source  code  for  the  first  testcase  (i.e.,  the  START-TERM  source  in- 
put) is  shown  in  Fig.  3.7.  This  listing  was  part  of  the  output  generated  dur- 
ing the  test  execution  phase  of  the  two  coverage  tests.  The  modules  invoked 
and  DD-paths  exercised  by  JAVS'  processing  of  this  small  START-TERM  sequence 
are  summarized  in  Figs.  3.8(a)  and  (b) . Since  subcomponent  JAVS-2C,  identi- 
fied as  the  J2C  JAVSTEXT  name  in  Fig.  3.8(a),  is  the  text  recognition  proces- 
sor, it  repeatedly  invokes  the  character  analysis  modules  (CGET,  CSIGN,  CTYPE, 
and  TC.ET)  . JAVS-2C  handles  the  flow  of  text  data  shown  in  Fig.  2.9,  starting 
with  extraction  from  the  input  source  line  into  characters,  through  symbol  and 
statement  recognition  and  building  of  text-related  tables. 

After  a 1 ' input  START-TERM  sequences  were  processed,  the  cumulative  sum- 
mary results  showed  73%  DD-path  coverage  of  the  invoked  JAVS-2C  modules.  Only 
JGETFACT  (containing  15  DD-paths)  was  not  invoked  during  the  test.  JGETFACT 
adds  the  scale  factor  to  the  current  JOVIAL  symbol;  there  were  no  scale  fac- 
tors in  the  input  source  data. 

Of  the  JAVS-2D  modules  invoked  during  processing  of  the  first  START-TERM 
sequence.  Fig.  3.8(b)  shows  that  64%  of  the  DD-paths  were  exercised.  The 
JAVS-2D  cumulative  results  from  processing  the  complete  200-line  input  source 
are  shown  in  Fig.  3.9.  The  uninvoked  modules  (10  for  JAVS-2D) , are  reported 
by  JAVS  following  the  summary  results.  In  this  test  the  uninvoked  modules 
dealt  with  JOVIAL  statement  types  which  were  not  present  in  the  test  coverage 
input  source  but  which  had  been  present  in  the  complete  input  source  used  for 
the  functional  test. 

The  summary  DD-path  coverage  report  is  intended  to  provide  a concise 
overall  picture  of  the  level  of  exercise  attained  by  the  program's  execution 
of  test  data.  It  is  usually  the  first  path  coverage  report  analyzed  by  the 
tester  and  focusses  his  attention  on  modules  that  were  not  invoked  at  all  or 
those  with  poor  path  coverage. 
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",  JAVSTEXT  label  compute  (COMPciL)" 

TEST 
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••  TEST  CASE  TO  IEST  LABEL  PROBLEMS  ** 

TEST 
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2 

START 

TEST 
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tP.OC  TSTLBL  (IDUKMIjS 

TEST 

s 

4 

item  icumiix  i 24  s$ 

TEST 

6 

5 

item  inox  i 2u  ss 

TEST 

7 

6 

aaaaaaaaaaa.  degin 

TEST 

8 

7 

inox  = -is 

TEST 

9 

8 

alabel. 

TEST 

10 

9 

INDX  « ItlDX 1 $ 

TEST 

11 

10 

CoTO  LABEJ.ES 

TEST 

12 

1 1 

goto  littles 

TEST 

13 

12 

ir  indx  eo  3s 

TEST 

14 

13 

goto  clabels 

TEST 

15 

14 

Goto  blabels 

TEST 

16 

15 

goto  swtch  <$indx$)  $ 

TEST 

17 

16 

if  indx  eq  ss 

TEST 

18 

17 

goto  elabels 

TEST 

19 

18 

SWITCH  SWTCH  * ( ALaBEL. BLABEL. LITTLE)* 

TEST 

20 

19 

blabel. 

TEST 

21 

20 

Indx  * indx-ms 

TEST 

22 

21 

CIOS*  LABELS  $ 

TEST 

23 

22 

8Z5IV 

TEST 

24 

23 

goto  clabels 

TEST 

25 

24 

End 

TEST 

26 

25 

GOTO  ALABELS 

TEST 

27 

26 

clabel. 

TEST 

28 

27 

indx  * -1$ 

TEST 

29 

26 

GOTO  CHOICE  ($INDX*1$)$ 

TEST 

30 

29 

SWITCH  CHOICE  > ( dlabel. blabel. cLabsl. DLaBEL ) $ 

TEST 

31 

30 

DLABEL. 

TEST 

32 

31 

indx  « indx+is 

TEST 

33 

32 

goto  aIabels 

TEST 

34 

33 

end 

TEST 

33 

3u 

iebhs 

TEST 
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Figure  3.7.  Source  Code  for  Testcase  1 
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Figure  i.3(a).  Path  Coverage  Summary  Report  for  JAVS-2C  (Testcase  1) 


Figure  3.8(b).  Path  Coverage  Summary  Report  for  JAVS-2D  (Testcase  1) 
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Figure  3.9.  Path  Coverage  Summary  Report  for  JAVS-2D  (Testcase  7) 


Subsequent  to  the  summary  report,  the  tester  may  want  to  review  the 
single  module  reports  which  show  the  number  of  executions  of  each  DD-path  and 
each  statement  (separate  reports)  accumulated  from  the  entire  test  input  data, 
along  with  the  report  showing  DD-paths  aot  executed  during  each  separate  test 
case  for  all  invoked  modules.  Additional  execution  performance  information 
can  be  obtained  by  requesting  module  invocation  and/or  DD-path  tracing  re- 
ports, a report  showing  execution  time  spent  in  each  module  during  the  test, 
and  reports  showing  the  DD-path  execution  count  by  module  and  testcase. 

To  demonstrate  the  usage  of  JAVS  path  coverage  reports,  consider  the 
following  analysis.  The  DD-path  summary  for  JAVS-2D  in  Fig.  3.9  showed  that 
module  MAKE  achieved  80%  path  coverage  and  has  the  most  DD-paths  in  the  sub- 
component. The  functional  description  for  MAKE  states  that  it  creates  the 
symbol  table  and  symbol  locator  table  entries  (control  symbols  only)  of  desig- 
nated symbol  types.  A partial  listing  of  the  cumulative  DD-path  coverage  re- 
sults is  shown  in  Fig.  3.10.  The  cumulative  execution  counts  are  given  in 
the  far  right  column.  In  the  partial  listing,  five  DD-paths  were  never  exer- 
cised. This  report  includes  the  first  statement  of  each  DD-path  and  shows 
the  importance  of  including  an  informative  comment  at  decision  points.  Re- 
testing can  be  particularly  aided  when  comments  refer  to  characteristics  of 
the  input  data. 

The  DD-path  coverage  listing  should  be  analyzed  along  with  a functional 
description  of  the  module,  a listing  of  the  input  data  used  (identified  by 
testcase  boundaries),  the  program's  execution  output,  and  the  JAVS  "not  hit" 
and  statement  coverage  reports. 

For  the  JAVS-2D  test,  the  "not  hit"  report  in  Fig.  3.11  shows  which  DD- 
paths  In  module  MAKE  were  not  executed  by  the  testcases.  Paths  4,  10,  12,  17, 
20  and  27  were  never  hit.  Each  of  these  paths  should  be  analyzed  to  determine 
if  they  can  be  executed  and  whether  additional  test  data  should  be  derived. 

DD-path  4 depends  upon  the  current  module  in  the  input  data  being  a 
C0MP00L.  A C0MP00L  was  provided,  but  it  did  not  contain  any  control  symbols 
(such  as  a PROC  declaration) . Thus  the  addition  of  a PROC  declaration  to  the 
C0MP00L  should  execute  Path  4. 

Proper  analysis  of  DD-path  10  requires  review  of  the  statement  coverage 
(or  other  JAVS  module)  listing  in  Fig.  3.12  and  the  functional  description 
document.  This  review  shows  that  DD-path  10  cannot  be  executed  since  the  con- 
ditions leading  up  to  path  10  are  (1)  the  symbol  is  global  (DD-path  2 is 
true),  (2)  the  module  is  not  a COMPOOL  (DD-paths  5 and  6 are  true),  and  (3) 
the  symbol  is  being  referenced,  not  declared  (DD-patu  9 is  true). 

DD-path  12  is  also  an  example  of  a DD-path  which  cannot  be  hit.  This 
one,  however,  can  be  analyzed  merely  by  looking  at  Paths  2,  3,  and  11,  12,  at 
statements  16  and  32,  respectively.  If  FLLOCAL  equals  0,  then  DD-path  2 is 
true,  and  neither  paths  11  or  12  will  be  executed.  If  FLLOCAL  is  not  0,  then 
DD-paths  3 and  11  will  be  executed.  In  neither  case  will  Path  12  be  hit. 

The  last  two  untested  paths  in  Fig.  3.10  deal  with  control  symbols  in 
formal  parameter  lists.  The  two  general  types  of  JOVIAL  parameters  allowed 
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Figure  3.10.  Partial  Listing  of  DD-path  Coverage  Report  for  Module  MAKE 
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Figure  3.11.  Partial  Listing  of  DD-paths  not  Executed  in  JAVS-2D  Modules 


are  input  or  output.  In  the  source  input  text,  there  was  an  occurrence  of  a 
label  output  parameter  (the  only  allowable  control  symbol  output  parameter) . 
To  exercise  DD-path  17,  the  source  text  must  include  a CLOSE  name  as  an  input 
parameter . 

The  analysis  described  in  the  above  paragraphs  is  the  type  of  procedure 
undertaken  to  evaluate  the  thoroughness  of  a program's  execution.  Sometimes 
additional  JAVS  documentation  reports,  such  as  the  module  invocation,  reach- 
ing set  or  symbol  cross  reference,  are  needed  to  understand  the  conditions 
required  to  execute  specific  paths. 

An  integral  part  of  program  path  testing  is  the  knowledge  of  the  proper 
and  complete  function  of  the  program.  As  was  seen  in  the  step-by-step  analy- 
sis of  paths  in  module  MAKE,  some  paths  cannot  logically  or  functionally  be 
executed.  In  addition,  it  is  often  the  case  that  certain  combinations  of 
paths  should  be  tested,  rather  than  merely  striving  for  the  minimal  set  of 
combinations  covering  a set  of  DD-paths.  These  considerations  should  be  made 
with  respect  to  the  module  or  program's  proper  function. 
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FUTURE  EFFORT 


JAVS  is  currently  a powerful  software  tool  for  providing  static  and  dy- 
namic analyses  for  JOVIAL  J3  programs  that  would  be  impractical  or  impossible 
to  achieve  manually.  Its  design  and  implementation  allow  extensions  in  syn- 
tax recognition  and  functional  capability.  The  modularity  and  clear  defini- 
tion of  processors  allow  interchange  of  software  components  when  new  tech- 
niques prove  themselves  better  (as  demonstrated  by  the  implementation  of  the 
new  syntax  analyzer). 

We  feet  that  the  capabilities  JAVS  now  has  offer  a valuable  asset  in 
the  testing,  maintenance  and  design  of  high  quality  JOVIAL  software.  Effort 
should  be  expended  in  further  disseminating  the  tool  and  training  JOVIAL  pro- 
grammers in  its  usage.  An  important  part  of  improving  the  acceptance  of  JAVS 
as  a useful  JOVIAL  software  tool  would  be  the  development  of  a document  on 
how  to  design  high  quality  software  with  JAVS'  assistance.  A workshop  which 
covers  software  development,  testing  and  maintenance  should  be  conducted  to 
stimulate  current  and  new  users  of  JAVS  to  take  advantage  of  the  tool's  capa- 
bilities. 

Several  static  and  dynamic  testing  techniques  can  be  added  to  JAVS'  cur- 
rent features  which  would  increase  its  automation  and  provide  more  stringent 
measures  of  software  testing.  Static  data  flow  analysis,  available  in  GRC ' s 
Fortran  Automated  Verification  System  (FAVS) , can  locate  use-before-set  er- 
rors (uninitialized  variables) , a common  source  of  program  errors  which  can 
be  difficult  to  find  manually  in  large  programs.  Physical  units  consistency 
checking  can  be  very  useful  in  mathematical  programs  using  engineering  units. 
This  static  analysis  feature  is  available  in  the  SQLAB  tool^  and  can  be  effi- 
ciently included  in  JAVS  along  with  set/use  checking,  since  both  analyses  re- 
quire much  of  the  same  software.  Automatic  generation  of  certain  types  of 
assertions  and  coverage  measurement  of  program  functions  as  specified  through 
comments  are  two  dynamic  testing  techniques  which  can  be  incorporated  into 
JAVS . 


The  above-described  added  capabilities  for  JAVS  would  continue  the  pur- 
suit of  increasing  testing  thoroughness.  Without  ignoring  that  goal,  we  feel 
that  computer  resources  should  be  kept  to  a minimum.  JAVS  now  operates  in 
53,000  words  of  primary  core  storage,  which  is  not  excessive.  We  have  found 
that  processing  time  can  be  greatly  reduced  in  FAV.  without  any  loss  of  capa- 
bility. Since  the  two  systems  (FAVS  and  JAVS)  have  similar  designs,  we  are 
confident  that  JAVS'  processing  time  can  also  be  reduced. 

4 . 1 JAVS  WORKSHOP 

A two-  or  three-day  workshop  for  JOVIAL  programmers  which  integrates  the 
concepts  of  good  software  design  and  testing  in  the  JAVS  environment  would  be 
very  beneficial  in  increasing  the  utilization  of  the  tool.  A workshop  would 
also  provide  the  opportunity  to  coordinate  and  formalize  quality  programming 
practices  and  their  effect  on  AVS-supported  testing  while  getting  immediate 
feedback  from  workshop  participants. 
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Tho  i'i'I  hvl  inn  ol  .IAVS  documents  listed  In  Sci' . 4.1  include  gu  i <li'  I I tics 
lor  using  .IAVS  (Usoi  ' ;;  Culdo)  .uni  .1  demons!  1 . 1 ( Ive  tost  lug  hum  hodo  I ogv  which 
( I s^s  1 1 1 > \ h^  IAVS  J^Mot  hodo  I ogv  Kopoi t ) . Novel  I he  I ess , wit.  1 1 seems  In  In 

1 .lik  lug  Is  .1  discussion  ol  how  .IAVS  com  1 Hull  os  .mil  shoulTT  he  us  oil  in  I In  InlT 
i .mgr  ol  si'ltw.iii'  lite-ovoio  .ill  l v 1 1 ios. 

•. . 7 STAT  1 ('  DATA  Kl ,0W  ANAI.YS  I S 

Most  .I0V1AI.  .11  comp  I 1 its  |H'i  torm  1 igorous  cheeks  on  I ho  oons  I si  ono  v ho 
twi'i'ii  declared  .mil  actual  usage  ol  symbols  .uni  pa  1 amet  o 1 s . Ol  hoi  oonlrol 
Mow  .momo  I i os , no(  iloloolotl  bv  I ho  oompiloi  bill  reported  bv  .IAVS,  .110  slim 
tur.il  Intinllo  loops  .mil  unro.ioh.ib  1 o ooilo.  Ono  common  source  ol  01101s  which 
is  currently  mulct  cot  oil  bv  0I1I101  oompiloi  01  .IAVS  is  tho  usage  ol  uninil  i.il 
1 red  variables.  Those  "use  hot  oro-sol  " errors  o.m  ho  vorv  ill!  I (cull  ( o do 
loot  manual lv  in  programs  with  complex  oonlrol  structures. 

A small  timet  ion  containing  tho  uninil  lull /oil  v.u  table  SUM  is  shown  in 
Fig.  4.1  along  with  the  slat  to  analysis  in  big.  4..’.  The  I po  ol  slal  io  anal 
vsls  roeommoiiiloii  I01  .IAVS  is  I ho  sot /use  chocking  ilomous  t t a t oil  in  (lie  lowoi 
h.il  I ol  Fig.  4 . .’ . 

Sl.it  io  anal  vs  is  Is  already  available  in  FAVS , which  was  ilevclopoil  bv  tlKU 
iiinlor  KAtfi  sponsor  sli  i p . Most  ol  the  ictpiiioil  soltwaro  I01  .IAVS  sol /use  analv 
sis  coulil  bo  supplied  bv  I ho  FAVS-  I rails  I at  ed-Fl'KTKAN  source  ooilo.  Two  ap 
proaehos  0.111  bo  taken  I o i 1100  rpo  1 a I o 1 ho  onhanoomonl  into  .IAVS:  I ho  syntax 
analv/.er  can  make  a third  pass  to  supply  I ho  roipiiiod  symbol  intorm.il  ion  01 
tho  onrroiil  symbol  cross-rot oreucc  table  inlormal ion  can  bo  adaplod.  In 
either  case,  tho  static  sol /use  chocking  0.111  bo  pot  1 01  mod  in  a .eparate  ovot 
lav  load  modulo,  I hereby  not  inoroasing  I ho  ourroni  core  storage  1 equ i 1 onion I . 

4.1  1’HYS  1 t'.Al.  UNITS  UIIFCKINC 

Requiring  that  local  .nul  global  vari.iblos  ho  spec  1 I I oil  in  I onus  ol  I he 
physical  units  I hov  roprosonl  (il  anv)  allows  comprehensive  chocking  ol  1 ho 
consistency  ol  units.  This  type  ot  chocking  Is  part  leul.it  lv  relevant  I o I00I1 
nioal  sot  t ware  whore  many  physical  propel!  ios  arc  represent  oil  and  I hero  .110 
many  pass  (hi  I it  Ios  ol  contusion  ovoi  unit;.-.  Units  o.m  bo  cheeked  on  .1  miiil  i 
module  hits  is  II  each  nodule  contains  a dosoi  ipl  ion  ol  I lie  nulls  loi  each  plivs 
leal  variable  Io  which  il  rotors.  Tho  lornt  ol  I ho  dosoi  Ipl  ion  loi  .IAVS  would 
be: 

".UNITS  (•vaiiablo  list  I ^ • nn 1 1 s-oxpross I on  I . 

•-variable  I i si  .’  '•  tin  i t s- ex  press  Ion  .’  ■ , ...  V 

The  mills  direct  ive  would  bo  placed  in  the  source  code  bv  the  usoi . 

.IAVS  would,  il  directed  bv  usoi  commands,  perloitn  the  following  analysis  ,1m 
lug  the  st.il  to  sol  /use  chocking.  A11  l noons  I si  onov  in  uiiils  is  indicated  il 
mil  Ike  units  are  added,  subt  1 act  oil , 01  compared.  The  plivs  I 0.1 1 -mi  1 1 s analysis 
compares  the  right  and  loll  side  ol  assignment  statements,  the  1 ight  and  loll 
side  ol  relat  ion.il  opera!  Ions,  and  actual  and  tormal  pa  1 amot 01 s . F01  oonvon 

ienco  in  stating  UNITS  assertions,  all  constants  are  assumed  to  bo  unit  loss. 
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THIS  PAGE  IS  BEST  QUALITY  PRACTICABLE 
KKUM  COPY  EURULSHfiD  TO  DOJ2. ^ 


SUBROUTINE  SETUSHl 
C 

RADIUS  = D I AMT  R / 2 
AREA  = PI  * RADIUS  *♦  2 
PRINT  1.  ( KAClUS.  ARE.A  ) 
1 FORMAT  l 2 (Ft. 2)  ) 

RETURN 

END 


Figure  4.1.  Listing  of  Subroutine  SETUSE 


S'ATIC  analysis  cont... 


SUBROUTINE  SETUSE 


N/*V£ 

CLASS 

mccc 

1ST 

STMT 

TOTAL 

USES 

LAST 

STMl 

ASSFRTEO 

USE 

actual 

USE 

PHYSICAL 

UNITS 

hacils 

LOCAL 

real 

3 

3 

5 

OIANTfi 

LOCAL 

RCAL 

3 

1 

3 

• 

SE.T/USE  ERROR 

* 

VARIABLE 

D1 AMTR 

US^D  BEFORE  being 

assigned  a 

VALUE 

area 

LOCAL 

REAL 

*♦ 

2 5 

pi 

LOCAL 

REAL 

H 

1 H 

- 

SeT/USE  error 

* 

variable 

PI 

usto  BEFORE  BEING 

ASSIGNED  A 

VALUE 

STM6CL  ANALYSIS  SUMMARY  ERRORS  mARNINGS 

SEY/USE  CHECKING  2 0 


Figure  4.2.  Static  Analysis  of  Subroutine  SETUSE 
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except  for  zero,  which  will  match  any  units  expression.  A variable  is  de- 
clared unitless  by  stating  that  its  units  expression  is  the  constant  1,  as  in 
4W  NfcSt { P b*  =»•  1 ) .-  F-i  gu rf  '*i Tl'*s llfWR’  a TfMM^'p^g'ram^sftbrout  ine  * ontalning  spec- 
ified units.  An  inconsistency  was  detected  in  which  area  was  computed  as: 

FEET  * FEET  = INCHES  * INCHES 

Note  that  the  user's  units  "FEET**2"  was  changed  to  "FEET  * FEET"  in  the  units 
error  message.  Units  checking  is  capable  of  simplifying  terms  for  cancella- 
tion of  units. 

This  output  was  generated  by  SQLAB,^  a GRC-developed  software  tool  which 
provides  software  quality  measurements,  dynamic  and  static  testing,  and  veri- 
fication through  symbolic  execution  for  PASCAL  and  FORTRAN.  The  techniques 
and  software  used  for  SQLAB's  units  checking  can  be  implemented  in  JAVS. 

4.4  AUTOMATIC  ASSERTION  GENERATION 

Two  types  of  dynamic  assertion  statements  can  increase  the  thoroughness 
of  testing  and  quality  level  of  the  software.  Both  types  of  assertion  could 
be  generated  automatically  by  JAVS  with  a small  amount  of  modification.  The 
assertions  are  array  bounds  checking  and  compound  predicate  analysis.  The 
situation  is  best  described  by  example. 

Figure  4.4  is  a module  listing  which  contains  several  JOVIAL  statements 
which  lend  themselves  to  analysis  via  assertions.  In  Statements  3,  10,  12, 

14,  16,  and  17  are  array  or  table  references  with  computed  subscripts.  If  any 
of  the  subscripts  are  out  of  the  boundaries  declared  in  this  module's  C0MP00L, 
the  adjacent  core  locations  will  be  erroneously  over-written.  JAVS  could 
automatically  generate  a JAVS  computation  directive: 

".EXPECT,  <name>  = <low  value>,  <high  value'"  " 

at  each  array  or  table  reference.  JAVS  would  pick  up  the  low  and  high  values 
from  the  declaration  statement  and  instrumentation  would  expand  the  assertion 
into  executable  code. 

The  effect  of  the  assertion  is  that  during  the  program's  execution,  any 
occurrence  of  an  out-of-bounds  subscript  would  produce  a line  of  output  giving 
the  subscript's  name  and  computed  value.  JAVS  could  also  provide  the  module 
name  and  statement  number  of  array  or  table  overflow. 

Statements  20  and  24  in  Fig.  4.4  contain  numeric  subscripts.  These 
would  be  less  prone  to  error  than  computed  subscripts,  but  it  might  be  wise  to 
automatically  generate  the  EXPECT  assertions  for  numeric  subscripts  as  well. 

For  thorough  testing,  JOVIAL  statements  which  contain  compound  predi- 
cates such  as  those  in  Statement  3,  10,  14,  and  24  in  Fig.  4.4  should  he  exe- 
cuted once  for  each  disjunctive  term.  For  example, 

IFEITH  ZT  EQ  PD  ($PPBEGINS$)  OR  ZT  EQ  PD  ($PP1FEITH$)  $ 
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S»HT  1CLNT.L1NE  SOuRCC... 
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ARE*  = Pi  . RA0ILS»»J 

* units  Error 
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- 
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ERRORS  WARNINGS 

GRAPH  CHECKING 
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UNITS  CONSISTENCY 
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NAME 

SCOPE 

type  moce 

u Sr  other  Information. . • 

SYMCOL  ANALYSIS  SUMMARY 


InPUT/ULTPUT  CHECKING 
SET/USl  CHECKING 
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AREA 


ERRORS  WARNINGS 
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The  above  report  resulted  from  this  routine: 


STATEMENT 

5Y*T 

LISTING 

IOENT .LINE 

SLChCuTluC  CIRCLE  (RADIUS.  AREA  1 

SOURCE... 

1 

SUBROUTINE  CIRCLE  (HACILIS,  AREA  ) 

2 

CAYA  PI  / 3.1,1b  / 

3 

units  i raoius: inches.  aktaaFEe i.«i,  Pin  l 

» 

INPUT  «/R/  RADIUS  ) 

s 

AREA  * PI  • RAC luS*  *2 

fc 

OUTPUT  ( / R / AREA  1 

7 

RETURN 

• 

two 

F i gu re  4.3. 


Phvs ica 1 


Units  Checking 
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Figure  4.4.  Module  Listing  for  Automatic  Assertion  Generation  Example 


should  be  exercised  for  both 

ZT  = PD  ( $PPBEGIN$)  and 

ZT  = PD  ( $PP1FEITH$) 

JAVS  could  automatically  generate  three 
statement : 


assertions  for  the  above  IFEITH 


".ASSERT,  ZT  EQ  PD  ($PPBEGIN$)  AND  ZT  NQ  PD  ( $PPIFEITH$) " 


".ASSERT,  ZT  NQ  PD  ($PPBEGIN$)  AND  ZT  EQ  PD  ($PPIFEITH$) " 

".ASSERT,  ZT  EQ  PD  ($PPBEGIN$)  AND  ZT  EQ  PD  ($PPIFEITH$) " 

In  this  example,  the  third  assertion  would  never  be  true,  but  that  may  not  be 
the  case  in  general.  The  currently  implemented  computation  directive  instru- 
mentation would  translate  the  assertions  into  executable  code.  During  execu- 
tion, the  message: 

JAVS'  ASSERT  = ZT  EQ  PD  ($PPBEGIN$)  AND 
ZT  NQ  PD  ( $PPIFEITH$)  AT 
STMT.  xxxx  IS  TRUE 

would  be  printed.  The  current  JAVS'  ASSERT  message  is  printed  when  the  condi- 
tion is  not  true,  but  for  compound  predicates,  it  would  be  more  efficient  to 
print  the  message  for  the  true  condition. 

For  both  array/table  and  compound  predicate  automatic  assertion  genera- 
tion, the  user  would  request  the  capability  via  a command,  thus  being  able  to 
turn  the  option  on  or  off  and  being  able  to  select  one  or  more  modules  as  tar- 
gets. Current  instrumentation  would  require  modest  modification  for  implemen- 
tation of  these  assertions. 

4.5  COVERAGE  OF  PROGRAM  FUNCTIONS 

Execution  coverage  reports  currently  available  in  JAVS  measure  DD-path 
and  statement  executions.  Also  available  are  the  module  invocation  and  DD- 
path  trace  reports.  A combination  of  these  two  current  features  in  terms  of 
descriptive  functions  would  be  very  useful. 

Figures  4.5  and  4.6  are  execution  coverage  reports  for  statements  and 
DD-paths,  respectively,  for  one  module  in  the  new  JAVS  syntax  analyzer.  Note 
how  useful  it  is  to  include  descriptive  functional  comments  at  each  decision. 
It  may  be  functionally  important  in  a program  that  a specific  sequence  of  DD- 
paths  be  executed.  JAVS  DD-path  coverage  analysis  may  report  that  each  DD- 
path  of  interest  was  executed,  but  the  order  of  the  paths  may  be  crucial  to 
the  correctness  of  the  program. 
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Figure  4.6.  Execution  DD-path  Coverage  Report 


E&IS  PAGE  I?  BEST  QUALITY  PRACTICA£L| 
•TOUM  OOj  i h ui\ji  J. iimi!  TO  DOC  

Therefore,  If  the  user  can  assert  that: 

1.  Locate  SLT  in  module  and  supply  if  needed 

^ ' c.  ■ ■ • * 

2.  Search  module  for  copy  of  SLT 

3.  Found 

4.  Return 

is  the  specific  flow  of  interest  for  the  module  in  the  figures,  then  JAVS 
should  translate  the  supplied  functional  comments  into  DD-path  numbers  and 
compare  the  sequence  against  the  actual  DD-path  trace  that  occurred  during 
execution.  A sample  DD-path  trace  report  for  a different  program  is  shown  in 
Fig.  4.7.  Currently,  it  is  left  to  the  user  to  find  the  appropriate  sequences 
of  paths.  JAVS  could  be  modified  to  report  the  existence  or  omission  of  the 
specified  functional  sequence.  The  only  burden  on  the  user  would  be  to  supply 
concise,  functional  comments  at  all  DD-paths  to  be  analyzed. 

4.6  REDUCTION  OF  PROCESSING  TIME 

GRC  is  currently  investigating  the  possibility  of  substantially  reducing 
the  computer  processing  time  of  FAVS.  This  experience  convinces  us  that  JAVS' 
processing  time  can  also  be  reduced.  Substantial  reductions  can  probably  be 
made  in  the  syntax  and  structural  analyses  and  in  the  algorithms  used  to  gen- 
erate documentation  reports. 
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Figure  4.7.  Excerpt  of  DD-path  Execution  Trace 
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This  appendix  describes  procedures  for  Installing  JAVS  on  the  HIS  6180 
*•  -0-ti'S-wnd  jfgj-  buLLdin^  the^  JAVS  absolute  file  from  source  text 

for  non-HlS  installations.  * ' ’ * 

A. I HIS- INSTALLATIONS 

The  following  files  should  be  copied  from  magnetic  tape: 

1.  HSTAR/JAVSHS  - random  H*  file  containing  linked  JAVS  program 

2.  JAVSXQ  - BCD  sequential  select  stream  for  using  JAVS  H*file 

3.  PRP00L  - BCD  source  for  data  collection  C0MP00L 

4.  JPROBESX  - BCD  sequential  select  stream  for  loading  data  collection 
rout ine 

5.  MAKBINPX  - ASCII  sequential  job  stream  for  compiling  data  collec- 
tion routines  (files  6-10) 

6.  PRCMPL-X  - BCD  source  for  data  collection  C0MP00L 

7.  PROBE-X  - BCD  source  for  data  collection 

8.  PROBI-X  - BCD  source  for  data  collection 

9.  PROBM-X  - BCD  source  for  data  collection 

10.  PROBD-X  - BCD  source  for  data  collection 

Filenames  1-4  listed  above  are  the  ones  described  in  the  JAVS  User's 
Guide.  Files  HSTAR/JAVSHS  and  JAVSXQ  are  used  during  JAVS  processing;  PRPOOL, 
JPROBESX  and  the  binary  files  generated  by  executing  the  job  stream  MAKBINPX 
are  used  during  Test  Execution. 

The  purpose  for  installing  the  JAVS  data  collection  routines  from 
source  is  to  allow  compilation  of  these  routines  using  the  installation's 
standard  version  of  the  JOCIT  JOVIAL  compiler.  Once  the  data  collection  rou- 
tines are  compiled  (by  executing  the  job  control  stream  MAKBINPX),  all  JAVS 
users  can  utilize  the  object  form  of  the  routines,  as  described  in  the  JAVS 
User's  Guide. 

A. 2 NON-HIS  INSTALLATIONS 

For  non-HIS  facilities,  the  installation  tape  consists  of  BCD  source 
code  for  the  JAVS  processor  and  data  collection  routines.  Figure  A.l  shows  a 
top-down  overview  of  the  JAVS  software  system.  Source  code  for  COMPOOLs  and 
executable  text  is  compiled  into  binaries  for  the  JAVS  components  and  data 
collection  group.  The  binary  files  are  arranged  into  overlay  links,  as  shown 
in  Fig.  A. 2,  to  build  an  absolute  file.  Table  A.l  Identifies  the  over  lav 
links  bv  name  and  the  functional  keyword  known  bv  JAVS, 
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Figure  A.l.  Overview  of  JAVS  Installation 
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TABLE  A.  1 
JAVS  COMPONENTS 

IDENTIFIER  NAME 


JAVS-0 

Command  & Control 

JAVS-1 

Storage  Manager 

JAVS- 2 

Primary  Module  Analysis 

BASIC 

JAVS-? 

Secondary  Module  Analysis 

STRUCTURAL 

JAVS-4 

Structural  Analysis 

STRUCTURAL 

JAVS-5 

Instrumentation 

INSTRUMENT 

JAVS-o 

Data  Collection  and  Reduction 

ANALYZER 

JAVS- 7 

Testcase  Assistance 

ASSIST 

JAVS-8 

Segment  Analysis 

ASSIST 

JAVS-9 

Program  Modification  Analysis 

DEPENDENCE 

JAVS-10 

Data  Base  Services 

JAVS-11 

Support  Subroutines 

JAVS-M 

Macro  Command  Processor 

FUNCTIONAL  KEYWORD 


The  source  tape  contains  the  COMPOOLs  and  executable  source  code  for  all 
JAVS  components  including  the  data  collection  routines.  The  tape  can  be  made 
to  have  an  end-of-file  mark  following  each  START-TERM  sequence  or  with  a sin- 
gle end-of-file  mark  terminating  the  entire  source  (preferable  for  installa- 
tions with  CDC  UPDATE  or  similar  maintenance  program).  In  either  case,  sin- 
gle- or  multi-file  source  tape,  the  arrangement  of  source  code  is  as  follows: 


tabu:  a .2 


source  ('OJ)K 

Do so r ipt  i on 

COM POOL 
I START-TERMs 
1 START-TERM 
COMPOOI, 

4‘>  START-TERMs 
COM POOL 
1 9 START-TERMs 
COMPOOI. 

1 START-TERM 
COMPOOI. 
t START-TERM 
COMPOOI, 

1 START-TERM 
COMPOOI. 

1 START-TERM 
COMPOOI. 

1 START-TERM 
COMPOOI. 

58  START-TERMs 
COMPOOI. 

4 START-TERMs 
I FORTRAN  rout  I no 
COMPOOI 
I STAR r TERMS 


AKKANOKMENT 

•IAVS  Component 

.IAVS-0 

•IAVS-0 

IAVS-M  (Uses  .IAVS-0  Ci  POOL) 

• IAVS-1 
.IAVS-  1 
.IAVS- 2 
JAVS-2 
.IAVS-  5,  -A 

• IAVS-),  -4 
.IAVS -5 
.IAVS- 5 
.TAVS-6 

.1 AVS-6 
.IAVS- 7,  -8 
.IAVS- 7,  -8 
.IAVS-1) 

.IAVS-0 
•IAVS- TO,  -II 
.IAVS- JO,  -11 

.IAVS-10  Inst. 1 1 lot  Ion  Dependent 

.IAVS- 10 

.IAVS-10 

ll.t  t ,i  collection 
O.i t a co  1 1 ci  I ion 


Modules  emit  a i n i tip,  machine  dependencies,  in  addit  ion  to  those  noted  in 
Table  A..’,  are  the  .IAVS- 2 COMPOOI.  and  1 SC  LAS , ITS  1)111.  and  ITSHOI.  in  the  .IAVS-10 
component  . The  machine  dependencies  in  the  .IAVS-7  COMPOOI.  deal  wilh  the  num 
he  i of  hits  per  chat  actct  and  the  number  <>l  elt.ir.iefers  pet  word.  Each  deel.it 
at  Ion  is  commented.  The  .IAVS-10  modules  1SCI.AS,  ITSDlll.  and  IISIU'I  depend  on 
the  internal  cliaractet  represi'tit  at  ion.  The  IAVS-10  CllMPtlOL,  START-TERMs 
tl.SETUP,  I .BREAD,  I.HWRIT,  LEND)  and  FORTRAN  module  listed  in  Table  A. 7 are  ran- 
dom I /0  t ent  i ties . 


The  JAVS  System  Design  and  Implementation  Manual'’  contains  functional 
descriptions  of  each  JAVS  component  and  module.  System  routines,  such  as 
those  providing  date  and  time,  which  are  directly  invoked  by  JAVS  are  listed 
in  Appendix  C and  in  the  module  index  of  that  document.  The  computer  listing 
in  the  remaining  pages  of  this  appendix  are  included  to  show  the  suggested 
load  sequence  of  the  compiled  JAVS  software.  Each  binary  file  name  is 
Bxxxxxx,  where  xxxxxx  is  the  JAVSTEXT  name  supplied  at  the  beginning  of 
each  START-TERM  sequence  on  the  source  tape. 
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ICEKT 

RFCB3?,C1 . JJ.VS  SBC  , S550  200  30  11 5 , 

HSTaR/JAVSaLL 

"SEK1C 

RFCBGRC 

LOVLOAD 

JETTON 

FORTRAN. ROGO 

LIBRARY 

Z* 

SELECT 

BFCBGRC2/BP0OL 1 

Ob J EcT 

C16.35304057|P0011  CO 

TRENT 

pool  1 04 

select 

BpC3GRC2/BCMPLlO 

OBJECT 

C20.230051878G10CF100 

TRENT 

G10CPL04 

SELECT 

3FCBGRC2/B10/BDSTEPO 

OBJECT 

J17,906040877DSTEPOOO 

TREND 

DSTET003 

select 

BECBGRC2/B10/BXHVALU 

OBJECT 

J 17.749040877IHVALU00 

TREND 

IHVALU06 

select 

BFC1»GRC2/E 10/BIS CE AS 

OBJECT 

J17.753040877I5CLAS00 

TRENT 

ISCLAS06 

select 

3FCBGRC2/B10/BOUTBUF 

OBJECT 

J17,876040877OUTBUr00 

TREND 

ouTBi’roe 

select 

BFCBGRC2/B1/BACTDAT 

OBJECT 

J13.834102276ACTDAT00 

TREND 

ACTDAJ09 

select 

BFCBGRC2/B1/BACTDMP 

OBJECT 

J 13,839  102276ACTD.1P00 

DR  END 

ACTDMpOe 

SELECT 

BFCBGSC2/B 1/BACTFRG 

OBJECT 

Jl3.845102276ACTrRGOO 

DREND 

ACTTRG1 1 

select 

BFC9C.RC:/31/BACTICH 

OBJECT 

J13.8S0102276ACTICHOO 

DREND 

ACTICH04 

SELECT 

BFCBGRC2/B1/BACTM0D 

OBJECT 

J13.8S7102276ACTMOD00 

DREND 

ACTfJOD  1 4 

select 

BFCBGRC2/B1/BACTOLD 

OBJECT 

J 1 3 , 866  102276ACTOLDPO 

DREND 

ACTOLOC8 

SELECT 

BECBGRC2/B1/BCRIfBG 

OBJECT 

J13.870102276CBTFRGP0 

TREND 

CRTFRGC5 

SELECT 

HFCFGRr2/r'1/9TMPPPG 

OBJECT 

Jl3.874102216TnrFRG00 

TREND 

dm ftr g 1 1 

SELECT 

BFcBGrC2/S l/BEHTKOD 

OBJECT 

J14. 128102276DMPMODD0 

0 R E N P 

CMENODCS 

SELECT 

BFCBGRC2/B1/BGETBLR 

OBJECT 

J13.884102276GETBLK00 

TREND 

GET8EK1  1 

SELECT 

BFCPGRC2/B1/EGETFRG 

OBJECT 

Jl3.904l02276GETrRGC0 

DREND 

GETPR.&U* 
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SELECT 

BrCBGRC2/Bl/BG£TL8I 

OBJECT 

J1U.00U102276GETLBT00 

dkind 

GETLBT24 

SELECT 

BTCBGRC2/B1/BGETLST 

object 

J14.041102276GETLST00 

dkend 

GETLST15 

select 

BrCBGRC2/B1/BGETMOD 

OBJECT 

J14.06U102276GETHOD00 

OKEND 

GETM0D12 

SELECT 

BFCBGRC2/B1/BGETTAB 

OBJECT 

J14.069102276GETTAB00 

dkend 

GETTAB08 

select 

BECBGBC2/B 1/BlCHrBG 

OBJECT 

J14.085102276ICHrRG00 

dkend 

TCHrBG17 

select 

BrC8GHC2/B1/BlrNDEP 

object 

J14.095102276IFNDEP00 

DKEND 

IPNDEpu 

select 

becbgrc2/bi/bIgtlit 

OBJECT 

J14. 104102276IGTLIT00 

dkend 

IGTLIT04 

SELECT 

8rCBGRC2/B1/BlGTW»D 

OBJECT 

J 1 4 , 109102276IGTWRD00 

DKEND 

IGTWRd  1 3 

SELECT 

BECBGRC2/B1/BINAKEP 

OBJECT 

J14, 1 l41O2276lnAKEp0O 

dkend 

IHAKEP04 

SELECT 

BFCBGRC2/B1/BISRTAB 

OBJECT 

J14, 124102276ISRTAB00 

dkend 

ISRTAB17 

select 

BFCBGRC2/B1/BLBFREE 

OBJECT 

J14,  135102276LBFREE00 

dkend 

LBFREE06 

select 

BrCBGRC2/B1/BLBnoVE 

object 

J14.148102276LBMOVE00 

DKEND 

Lb«OVE06 

select 

BFCBGHC2/B1/BI-BTGET 

OBJECT 

J14, 154102276LBTGETOO 

dkend 

LBTGEJ06 

select 

BFC0GRC2/BVBLBTPUT 

OBJECT 

J14, 161102276LBTPUTOO 

pK  END 

LBTPUT06 

select 

&FCBGRC2/B1/BLBZEH0 

OBJECT 

J 1 4 , 166102276LBZERO0O 

dkend 

LBZERO06 

select 

BFCBGRC2/B1/BLGTBLK 

OBJECT 

J14.171102276LGTBLK00 

dkend 

LGTBLK09 

select 

«rCBGRC2/B1/BLGTWRD 

object 

J14, 176102276LGTWRDC0 

dkend 

LGTWR008 

SELECT 

BFCBGRC2/B1/BLPTBLK 

OBJECT 

J14. 18  1 102276LPTBLROO 

dkend 

LPTBLK09 

SELECT 

8FCBGRC2/B1/BLPTWFD 

object 

J 1 4 , 186102276LPTWRD00 

dkend 

LPTWRdOS 

select 

BrcBGRC2/B1/BMAKrR0 

object 

Jl4,193102276lAKrRG00 

dkend 

KAKFRG10 

SELECT 

BFCBGRC2/B1/BHAKK0D 

object 

J 14. 197102276 MAKSOD00 

dkend 

MAKB0D14 

SELECT 

BrcBGRC2/B1/BflDBGEI 

OBJECT 

J1U.2071022761DBGET00 
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SELECT 

BFCBGRC2/P 1/BKDBPUT 

OBJECT 

J1«,213102276MDBPUT00 

T K E N D 

MDBP0T07 

SELECT 

BrC3GKC2/Bl/BPL'TBLK 

object 

J1U.236102276PUTBLR00 

T K E N D 

putblkiu 

SELECT 

BECBGRC2/B  1/BP  U HIT 

OBJECT 

J14.241 102276PUTLIT00 

pKEND 

PUTLIT04 

SELECT 

6FC8GRC2/B 1/BPUTLST 

OBJECT 

J1U.2U71C2276PUTLST00 

OKEND 

PUTLST27 

SELECT 

bFCBGRC2/B1/sPUTwRD 

object 

J1U.254102276PUTVRD00 

DKEKD 

PUTWRd  1 6 

select 

bEC9GRC2/B1/bUPDEPT 

OBJECT 

J14.261 102276UPDEPTOO 

dkend 

UPDEPT16 

select 

BrC3GRC2/B 1/BMREPUP 

OBJECT 

Jl4.268102276WRApyp0O 

dkend 

WRAPUP04 

SELECT 

BFcBGRc2/B1/BWSGrRG 

OBJECT 

J14.277102276WSGFRG00 

dKEND 

WSGFRG07 

SELECT 

Brc3GRc2/S 1/BWSGWRD 

OBJECT 

J14.2B1 102276WSGWRd00 

dkenc 

WSGVRD07 

SELECT 

BrcBGRc2/B1/BWSPrRG 

OBJECT 

J14, 286102276 VSPFRGOO 

DKEND 

WSPTRG07 

SELECT 

SFCBGRC2/B1/BWSFWRD 

object 

J14.335102276USPWRD00 

dKEND 

WSPWRD07 

SELECT 

BFcbGHc2/b10/BKDbDAD 

object 

J17.672040877nDBD»D00 

dkend 

HD9DAD05 

SELECT 

8FCBGRC2/B10/BMDBMOD 

OBJECT 

J17.699040877KD3MOD00 

dkend 

Kp3«OD05 

SELECT 

BFCBGRC2/B1C/BMDBTXT 

OBJECT 

J17.703040877MDBTXT00 

DKEND 

MD3TXX05 

SELECT 

BFCBGRC2/310/BERROR 

OBJECT 

J20.245051878EBR08  00 

dkend 

ERROR  06 

SELECT 

BFCBGRC2/BlO/BrAT»L 

OBJECT 

J17.736040877FATAL  00 

DKEND 

fatal  06 

SELECT 

BFCBGRC2/B10/BGTCARD 

object 

J^7.740040877GTCARD00 

dkend 

GTCARD06 

SELECT 

BFC6GRC2/B10/ SllSf  RG 

OBJECT 

J17.76 1040877ITSFRG00 

dkend 

ITSrRG04 

select 

BFCPGRC2/E 1C/PITSH0L 

OBJECT 

J17.766040877ITSHOL00 

TREND 

ITSKOL07 

SELECT 

BrCB3RC2/PlO/BLENTAB 

OPJECT 

J17.775040877LE»TA300 

DKEND 

LENTAB0J 

select 

BFCbGRC2/BlO/BKOYEWD 

OB JEc~ 

Jl7.779040877f1OVEWDC0 

DKEND 

NOVEWD06 

SELEcT 

BFcjGRc2/310/BVFRGS: 

OBJECT 

J17.784040877NFRG3Z00 

PK  END 

‘’FAG3Z03 
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dkend 

select 

object 

dkend 

SELECT 

object 

dkend 

SELECT 

object 

dkend 

select 

object 

dkend 

SELECT 

object 

dkend 

select 

object 

DkEND 

SELECT 

OBJECT 

DKEND 

SELECT 

OBJECT 

dkend 

SELECT 

object 

dkend 

SELECT 

object 

DKEND 

SELECT 

OBJECT 

dkend 

SELECT 

OBJECT 

DKEND 

SELECT 

OBJECT 

dkend 

select 

object 

dkend 

SELECT 

OBJECT 

DKEND 

select 
object 
dk  end 
select 

OBJECT 

dkend 

LINK 

ENTRY 

SfLtCj 

object 

dkend 

select 

object 

dkend 

select 

object 


BTCB6RC2/B10/BNOHHDB 

Brc»GRC2/BlO/BNUMSB 

8TCBGRC2/310/BNUMSDB 

BrCBGRC2/BlO/BNUMSLT 

BrceGRC2/BlO/BHUBSTB 

BECBGRC2/B10/BPRDBG 

BFCBGRC2/B10/BSPRTHD 

BEcBGRc2/BlO/BLBcHPL 

BrCBGRC2/B10/BLSEIUP 

BECBGRC2/B10/BLBREAD 

BECBGRC2/B10/BLBWRXT 

bTcbgrc2/bio/blbio 

BECBGRC2/B10/BLEND 

BECBGRC2/B10/BSHDATE 

SECBGRC2/BCtlptOX 

BECBGRC2/BSRCE0L 

8FCBGRC2/BCCRACK 

BPC5GRC2/BGTLIN 

LINK  1 

stepi 

BFCBGRC2/NB2/BJ2A 

BFCBGRC2/NB2/BaZaP 

BFCBGrC2/NB2/BBZaP 


J17.845040877NUHHDB00 

NUHNDB03 

J17, 860040877 NUNSB  00 
NUHSB  03 

J17.864040877NU1SDB00 

NUHSDB03 

J17.868040877NUnSLT00 

NUMSLT03 

J17.672O4O877NUHSTB0O 

NU«STfl03 

J17.885040877PRDBG  00 
PBDBG  07 

Jl7,901040877SpRY«D00 

SPRTWD04 

Cl7,9lU040877EBC.1PL00 

IBCBP103 

J17.918040877ESET'JP00 

LSET0P15 

J 17, 92304 08771BREAD00 
LBREAD08 

J17.927040877EBWRXT00 

EBWRITI 1 

H7.928040877LBIO00OO 

LBI00006 

J17.933040877EEHD  00 

LEND  04 

J17.869040877SHDATE00 

SHDATE04 

C15.534051678G0CHPL00 

G0CMPL03 

J15. 539051678, 00 

92 

J15.542051678CCRACK00 

CCRACK18 

J15.544051676GTZ.XN  00 
GUI»  11 


J22.442051878J2A  00 

J2A  15 

J22.444051878AZAP  00 

AZAP  03 

J22.446051S786ZAP  TO 
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StLEcr 

BPC3GRC2/N  BZ/Bc  Z A F 

OBJECT 

J22.44b051b78CZAP 

00 

DKEND 

CZAP 

03 

SELECT 

BrCBGRC2/NB2/BDZ*P 

OBJECT 

J22.450051878DZAP 

00 

DKEND 

djap 

05 

SELECT 

BFCBGRC2/NB2/8EZAP 

OBJECT 

J22.4S2051878EZAP 

00 

dkend 

EZAP 

03 

SELECT 

Brc8GRC2/NB2/BIZ*P 

OBJECT 

J22.4540S18TBIZKP 

00 

ckend 

HAP 

05 

select 

BFC3GRC2/NB2/3JAVZAP 

object 

J22.456051878JavZAP0O 

dkend 

JAVZAP05 

SELECT 

BPc63HC2/Nb2/BJZaP 

OBJECT 

J22.458051878JZAP 

00 

dkend 

JJAP 

05 

select 

BFCEGRC2/NB2/BLZaP 

OBJECT 

J22.460051B78LZAP 

00 

DKEND 

LZAP 

05 

select 

BFC3GRC2/NB2/BKODZAP 

OBJECT 

J22.462051878NODZAP00 

DKEND 

MODZAI 

’10 

select 

8FCBGRC2/NB2/BSTZAP 

OBJECT 

J22.464051878STZAP 

00 

dken© 

SXZAP 

06 

select 

BTC3GRC2/NB2/BSZAP 

OBJECT 

J22.466051878SZAP 

00 

dkend 

SZAP 

05 

SELECT 

BFCBGRC2/NB2/BTZAP 

OBJECT 

J22.468051878TZAP 

00 

dkend 

TZAP 

03 

select 

3rCBGRC2/NB2/BKGET 

OBJECT 

J22.470051878NGET 

00 

dkend 

NGET 

04 

select 

BFCBGRC2/NB2/BMPUT 

object 

J22.472051878MPUT 

00 

dkend 

BPUT 

04 

LINK 

LlNKB 

ENTRY 

FINIT 

select 

BFCBGRC2/NB2/BJ2B 

OBJECT 

J22.479051878J2B 

00 

dkend 

J2B 

85 

select 

BFCEGhC2/31/oMaKTAB 

object 

J14,202102276«aKTAB00 

DKEND 

MAKTAB08 

LINK 

I.INKC.  LINKB 

ENTRY 

EONE 

sElect 

BFCBGRC2/N'P2/BJ2C 

odject 

J22.49405187802C 

00 

DKEND 

J2C 

50 

LINK 

LlNKD.LIUKC 

entry 

ft  VO 

SELECT 

BECBGFC2/NE2/B22D 

OBJECT 

J22.503051878J2D 

00 

dkend 

J2D 

89 

LINK 

LlNKCr . link  1 

ENTRY 

GETVRD 

SELECT 

BFC»GRc2/NbPOOL3 

OBJECT 

C16.6B60510T8POOL3 

00 

DKEND 

POOL3 

07 

select 

RFCBGrC2/NBPcOL5 

OBJECT 

Cl7,267040578r00L5 

00 

dky  ho 

POOLS 

08 

SELECT 

ercBGRC2/NBPOOL7 
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OBJECT 

c15. 191051678POOL7  00 

dkend 

P00L7  03 

select 

BTCB0RC2/BP00L9 

object 

C13.453060377P0OL9  00 

dkend 

P00L9  03 

SELECT 

BPCB0BC2/8P00L6 

object 

C19.963101376POO16  00 

DKEBD 

POOL6  03 

select 

BPCB81C2/B1/B5ETWBD 

OBJECT 

J1U.0741O2276OETNRp00 

dkend 

GETURD04 

SELECT 

BPcBSRc2/B1/BIT*BEP 

object 

J14, 1 19102276ITABEP00 

dkend 

ITABEP04 

SELECT 

BrCBGBC2/B1/Bl-B«EBG 

OBJECT 

J14.33o102476Lb«EB500 

dkend 

LbJIERq  15 

SELBCT 

BrCB0RC2/B1/BHAKTAB 

OBJECT 

J14.202102276NAKTAB00 

dkend 

WAKTAB08 

select 

BrCBGRC2/B1/B«KVTAB 

OBJECT 

J14, 22010227  StlKVTAjjOO 

dkend 

flKVTABOS 

select 

BrCBGRC2/BlO/BP»DVAL 

OBJECT 

J18.003040877PRDVAL00 

dkend 

PRDVAL12 

select 

bEcbgrc2/b 10/BPBeHTH 

OBJECT 

J17.982040877PREHTH00 

dkend 

PREBTH07 

SELECT 

B?CBGRC2/BlO/BpRsKEL 

OBJECT 

J17.998040877PRSKEL00 

dkend 

PBSXEL26 

select 

BrCBGRC2/BlO/BpHxniH 

OBJECT 

J20.232051878PRTMTK00 

dkend 

PRTNTH 1 8 

SELECT 

BPCBGRC2/B10/BPSTBTH 

OBJECT 

J17.992040877PSTMTH00 

DKEND 

PSTMTH22 

select 

BrCBGRC2/BlO/BGETVAR 

object 

J17.937040877GETVAR00 

dkend 

GETVAR06 

SELECT 

BPCBGRC2/B10/BMTHDDP 

OBJECT 

J17.942040877HTHDDP00 

DKEND 

NIHDDP09 

select 

BECBGRC2/B10/8SORTAB 

OBJECT 

J 17, 947040877  SORT ABOO 

DKEND 

SORIAB08 

select 

BPCBGRC2/B10/BTGTBIT 

OBJECT 

J17.953040877IGTBIT00 

dkend 

IGTBTT05 

SELECT 

BPCBGRC2/B10/BPUTBIT 

OBJECT 

J17, 96 1040877PUTBIT00 

^KEND 

PUTBH06 

select 

bPcbGrc2/biO/biseleh 

object 

J17.957040877TSELEM00 

dkend 

ISELEH04 

select 

BECBGRC2/B 10/BrNDLB 

object 

J17.966040877PNDLB  00 

DKEND 

TNDLB  08 

select 

BPCBGRC2/B10/BNXTEX 

object 

J17.972040877NXTEX  00 

DKEND 

NXTEX  19 

SELECT 

BECBGRC2/B10/BsCaNSB 

OSJtCT 

J17.977040B773CANSBOO 
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SELECT 

8ECBGRC2/BlO/BpRftBbP 

OBJECT 

J17.707040877PinBUrOO 

DKEND 

PH«»uro7 

SELECT 

BFCBGRC2/BlO/BpRhODL 

OBJECT 

J17.712040877P*(1ODL00 

DKEND 

P8H0DL16 

select 

Brc«GRC2/BlO/BFRsTnT 

OBJECT 

J17.717040877PRSTBT00 

DKEND 

PRSTHH4 

select 

erce5RC2/BlO/BAN*LEE 

OBJECT 

J17.910040877ANALEX00 

DKEND 

ANALExiS 

select 

BECBGRC2/B10/BBALPAH 

OBJECT 

J17.7220408778ALPA100 

DKEND 

BALPA106 

select 

BECBGRC2/B10/DBEDLIN 

OBJECT 

J20.235051878BLDHN00 

DKEND 

BLDLI>20 

select 

prC3GRC2/BlO/BIGTSTB 

OBJECT 

J17.745040877IGTSTB00 

DKEND 

IGT5TB06 

select 

BECEGSC2/B10/BITSDHL 

OBJECT 

J17.757040877ITSDHLOO 

dkent 

ITSOHL05 

select 

BrCBGRC2/BlO/BjDENT 

OBJECT 

J17.771040877JDENT  00 

DKEND 

JDENT  14 

SELECT 

bEcbgrc2/bi0/bnuhdmt 

OBJECT 

Jl7,812040877NUB0flT0O 

DKEND 

NUfIDflT03 

SELECT 

BrCBGRC2/BlO/BNUnDDP 

OBJECT 

J17.788040877NUHDDP0O 

DKEND 

NJHDDP03 

SELECT 

BEC3GRC2/B10/BNUBDS 

object 

J17.825040877NUNDS  00 

DKEND 

NUBDS  03 

5ELECT 

BECBGRC2/BlO/BNUr.EPT 

OBJECT 

Jl7.829040877NUnEPT00 

DKEND 

NUMBPT03 

select 

BECE5RC2/3lO/BHUKrDI 

object 

J17.G3304O877NUBPDT0O 

DKEND 

NUMPDT03 

select 

BECBGRCZ/dIO/BNE’KH'*.! 

object 

J17.S49040877NUMBLTOO 

DKEND 

NUHMLT03 

SELECT 

8EC2GRC2/B',0/3NUBOCS 

CB JECT 

J17, 855040877NUBODS00 

DKEND 

NUP10DS03 

SELECT 

0EceGRC2/BlO/BNUNPRB 

OBJECT 

J17, 840040877NII«PPb00 

DKEND 

NU«P«B03 

SELECT 

BFCpGRCD/BlC/BPDKPUr 

OBJECT 

J17 .661O40877PCHBUP0O 

DKEND 

PCHBUP04 

SELECT 

BECBGKC2/&^0/BSETSTb 

OBJECT 

J17.B93040877SLTSTB00 

DKEND 

SLTSIB07 

SELECT 

BFCBGRC2/D10/3SCRT 

OBJECT 

J17.898040877S0RT  00 

DKEND 

SOXI  08 

LINK 

LINKS 

ENTRY 

STSTOP 

select 

bEcsgrc2/bi/bsi$top 

OBJECT 

JH.395040578STSTOP00 

dkeno 

STSTOpm 

LI  NK 

LlNKP. LINKS 
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ENTRY 

stprop 

select 

BFCBGRC2/B10/BSTPROP 

J2O.243O51B78STPROP00 

OBJECT 

dkend 

3TPR0P44 

LINK 

linkh.linkp 

ENTRY 

hACROC 

select 

BFCBGRC2/BMACRO 

J16, 648040578  HA CIOC00 

OBJECT 

dkend 

HACROC59 

LINK 

HNK2.LHKH 

entry 

STEP2 

select 

BFC6GRC2/NBINBY3 

J16.736051078SORCE300 

OBJECT 

dkend 

S0RCE514 

link 

LINK3.LINK2 

ENTRY 

STEP3 

select 

BrCBGRC2/NBlNRY5 

J17.297040578SORCE500 

OBJECT 

dkend 

SOSCE880 

LINK 

LlNKU . LINK3 

ENTRY 

STEPU 

SELECT 

BFCBGRC2/NBINRY7 

J15.205051678SORCE700 

OBJECT 

DKEND 

S0RCE937 

LINK 

LINK5.LINK4 

ENTRY 

STEP5 

select 

BFCBGRC2/BINARY9 

J13.482060377SORCE900 

object 

DKEND 

SORCE086 

LINK 

LINK6. LINKS 

ENTRY 

STEP  6 

select 

BFCBGRC2/BSORCE6 

Jl9.997101376SoRcr600 

OBJECT 

dkend 

execute 

SQRCE842 

pRmfl 

a*»R.S.BPCBGRC1/JOVLlB 

LIJ1ITS 

10,55k.-5K 

PRMFL 

H*.R/N.R,BPCBGRC1/HSIaR/JaVSKS 

PILE 

lO.CIH.E 

THE 

Ol.XIR.R 

PILE 

02.X2R.R 

FILE 

03.X3R.R 

FILE 

04.XUR.L 

PILE 

07,x7r,L 

FILE 

08,x8r.L 

PILE 

endjob 

09,x9r,L 
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ABSTRACT 


The  JOVIAL  Automated  Verification  System  (JAVS)  is  a control-path 
testing  tool  which  analyzes  source  programs  written  in  the  J3  dialect  of 
the  JOVIAL  language.  From  the  user's  viewpoint,  JAVS  consists  of  a sequence 
of  processing  steps  which  (1)  builds  a database  containing  syntactical  and 
structural  information  about  his  JOVIAL  source  text,  (2)  prepares  documenta- 
tion reports  describing  inter-  and  intra-module  characteristics  of  the 
source  code,  (3)  measures  control-path  coverage  during  program  execution, 
and  (4)  assists  in  pinpointing  untested  source  code  and  preparing  additional 
test  data. 

The  purpose  of  this  document  is  to  introduce  the  tester  to  JAVS  and  to 
the  process  of  software  testing  supported  by  JAVS.  The  information  provided 
in  this  guide  on  JAVS  usage  is  intentionally  limited  to  the  beginning  user. 
The  appendixes  provide  the  information  necessary  for  operating  JAVS  at  RADC 
and  can  be  referenced  by  the  sophisticated  as  well  as  the  beginning  user. 

The  information  presented  on  the  testing  methodology  which  JAVS  supports  is 
applicable  to  both  the  beginning  and  sophisticated  user  of  JAVS. 
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The  purpose  of  this  guide  is  to  introduce  the  user  into  the  realm  of 
automated  testing.  Software  testing  supported  by  an  automated  verification 
svstem  requires  knowledge  of  two  inseparable  factors:  the  verification  tool 
and  the  testing  methodology  which  the  tool  supports.  The  information  concern- 
ing the  usage  of  JAVS  is  intentionally  limited  to  the  beginning  user.  The 
only  prerequisite  information  is  a knowledge  of  the  JOVIAL  language.  The 
casual  user  should  have  good  success  in  analyzing  the  behavior  of  his  programs 
using  the  description  of  JAVS  capabilities  and  a few  commands  set  forth  in 
this  guide.  All  job  control  and  file  information  is  presented  in  appendixes, 
along  with  estimates  of  processing  time  and  core  requirements. 

The  testing  methodology  which  JAVS  supports  is  described  in  this  guide 
because  of  its  importance  to  JAVS  users  at  all  levels  of  expertise.  Although 
there  is  no  single  general  methodologv  which  applies  to  all  testing  situations, 
there  are  a number  of  important  issues  that  even  the  beginning  verification 
tool  user  should  recognize  in  order  to  make  the  testing  experience  successful. 
Section  10  o.  this  guide  focuses  on  software  preparation  for  JAVS-supported 
testing,  testing  goals,  resources  required,  and  testing  strategy. 

In  the  series  of  JAVS  reports,  this  guide  should  be  read  first.  The 
information  presented  should  enable  the  tester  to  become  a new  user  of  JAVS 
at  RADC . Once  the  user  has  experienced  some  of  the  capabilities  that  JAVS 
offers,  the  JAVS  Reference  Manual^  should  be  used  to  supply  the  complete 
details  of  JAVS  features  and  command  language. 

For  more  comprehensive  treatment  of  software  testing  methodology  not 
restricted  solely  to  JAVS-supported  testing,  the  reader  is  referred  to  the 
Methodology  Report . This  report  describes  experiences  with  using  current 
Automated  Verification  Systems,  approaches  to  software  quality,  and  advanced 

AVS  capabilities. 

SPECIAL  INSTRUCTIONS: 

This  User’s  Guide  supersedes  the  JAVS  User's  Guide,  dated  November  1976. 
Change  bars  in  the  page  margins  indicate  additions  and  changes  to  the  1976 
guide;  asterisks  denote  deletions. 
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LIST  or  JAVS  REPORTS 


• Revised  Methodology  for  Comprehensive  Software  Testing.  This  report  de- 
scribes the  methodology  which  underlies  and  is  supported  by  JAVS.  The  method- 
ology is  tailored  to  be  largely  independent  of  implementation  and  language. 

The  discussion  in  the  text  is  intended  to  be  intuitive  and  demonstrative.  Some 
o£  the  methodology  is  based  upon  the  experience  of  using  JAVS  to  test  a large 
information  management  system.  A long-term  growth  path  for  automated  verifica- 
tion systems  that  supports  the  methodology  is  described. 

• JAVS  Technical  Report:  Vol. 1,  User's  Guide.  This  report  is  an  intro- 
duction to  using  JAVS  in  the  testing  process.  Its  primary  purpose  is  to  acquaint 
the  user  with  the  innate  potential  of  JAVS  to  aid  in  the  program  testing  pro- 
cess so  that  an  efficient  approach  to  program  verification  can  be  undertaken. 

Only  the  basic  principles  by  which  JAVS  provides  this  assistance  are  discussed. 
These  give  the  user  a level  of  understanding  necessary  to  see  the  utility  of 

the  system.  The  material  on  JAVS  processing  in  the  report  is  presented  in  the 
order  normally  followed  by  the  beginning  JAVS  user.  Adequate  testing  can  be 
achieved  using  JAVS  macro  commands  and  the  job  streams  presented  in  this  guide. 
The  Appendices  include  a summary  of  all  JAVS  commands  and  a description  of  JAVS 
operation  at  RADC  with  both  sample  command  sets  and  sample  job  control  state- 
ments . 

• JAVS  Technical  Report:  Vol.  2,  Reference  Manual.  This  report  describes 
in  detail  JAVS  processing  and  each  of  the  JAVS  commands.  The  Reference  Manual 
is  intended  to  be  used  along  with  the  User's  Guide  which  contains  the  machine- 
dependent  information  such  as  job  control  cards  and  file  allocation.  Through- 
out the  Reference  Manual,  modules  from  a sample  JOVIAL  program  are  used  in 

the  examples.  Each  JAVS  command  is  explained  in  dcLail,  and  a sample  of  each 
report  produced  by  JAVS  is  included  with  the  appropriate  command.  The  report 
is  organized  into  two  major  parts:  the  first  four  sections  describing  the  JAVS 
system  and  the  fifth  section  containing  the  description  of  eacli  JAv:  command  in 
alphabetical  order. 

The  Appendices  include  a complete  listing  of  all  error  messages  directly 
produced  by  JAVS  processing. 

• JAVS  Computer  Program  Documentation:  Vol.  1_,  Svs  tern  Design  and  i rnp  lemon - 
ta  t ion . This  report  contains  a description  of  JAVS  software  design,  the  organi- 
zation and  contents  of  the  JAVS  data  base,  and  a description  of  the  software 
for  each  JAVS  component:  its  function,  each  of  the  modules  in  the  component, 
and  the  global  data  structures  used  by  the  component.  The  report  is  intended 
primarily  as  an  informal  reference  for  use  in  JAVS  sof tware  maintenance  as  a 
companion  to  the  Software  Analysis  reports  described  below.  Included  in  the 
appendices  are  the  templates  for  probe  code  inserted  by  instrumentation  pro- 
cessing for  both  structural  and  directive  instrumentation  and  an  alphabetical 
list  of  all  modules  in  the  system  (including  system  routines)  with  the  formal 
parameters  and  data  type  of  each  parameter. 

• JAVS  Computer  Program  Doc umenta tion:  Vol ■ 2,  So  It  wa  r e Ana  1 y s i s . Th i s 
volume  is  a collection  of  computer  output  produced  by  JAVS  standard  processing 
steps.  The  source  for  each  component  of  the  JAVS  software  has  been  analyzed 
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to  produce  enhanced  source  listings  of  JAVS  with  indentation  and  control  struc- 
ture identification,  inter-module  depencence,  all  module  invocations  with  formal 
and  actual  parameters,  module  control  structure,  a cross  reference  of  symbol 
useage,  tree  report  for  each  leading  module,  and  report  showing  size  of  each 
component.  It  is  intended  to  be  used  witli  the  System  Design  and  Implementation 
Manual  for  JAVS  software  maintenance.  The  Software  Analysis  reports,  on  file 
at  RADC,  are  an  excellent  example  of  the  use  of  JAVS  for  computer  software 
documentation. 

• JAVS  Final  Report.  The  final  report  for  the  project  describes  the  design, 
implementation  and  testing  of  the  JAVS  syntax  analyzer.  Background  information 
regarding  all  JAVS  contracts  is  provided  as  well  as  procedures  for  installing 
the  complete  JAVS  software  package.  This  report  contains,  as  appendices, 
the  June  1978  updated  pages  for  the  User's  Guide  and  Reference  Manual  published 
as  RADC-TR-77-126 , Vols.  1 and  II,  April  1977. 
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The  process  oi  program  verification  is  best  described  by  example.  One 
purpose  of  this  User's  Guide  is  to  present  an  overview  of  JAVS  capabilities 
through  example  programs  processed  by  the  JAVS  execution  steps.  It  is  impor- 
tant to  note  that  while  there  are  six  processing  steps  a given  validation 
effort  may  require  use  of  only  a few  of  these.  The  selection  of  appropriate 
processes  is  largely  a user  decision,  based  upon  his  requirement  for  the 
information  that  the  various  steps  provide.  As  each  step  is  described, 
through  example,  the  user  will  gain  insight  into  its  utility  for  his  particular 
needs.  In  order  to  develop  a basic  understanding  of  the  processing  sequences 
to  be  utilized  in  the  examples.  Fig.  2.1  illustrates  the  potential  JAVS  processing 
flows  in  terms  of  step  interdependencies. 
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The  user  must  provide  three  major  types  of  input  to  JAVS:  (1)  the  source 
code  to  be  tested,  (2)  a set  of  commands  to  direct  JAVS  processing,  and  (3) 
test  data  for  program  execution.  Section  2.2  describes  the  preparation  of  the 
source  code  for  input  to  JAVS.  Section  2.3  describes  the  rules  for  inputting 

commands . 
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2.1  TYPICAL  PROCESSING  SEQUENCE 

This  guide  is  organized  to  lead  the  user  through  the  following  sequence 
of  steps: 

1.  Build  a data  base  library  containing  source  text  and  structural 
analyses  (Sec.  3). 

2.  Document  the  source  text  (Sec.  4). 

3.  Instrument  the  modules  (Sec.  5). 

4.  Execute  the  program  (Sec.  6). 

5.  Measure  the  test's  effectiveness  (Sec.  7). 

6.  Retest  the  program  (Sec.  8). 

These  steps  provide  the  primary  assistance  needed  to  generate  test  cases 
and  measure  the  extent  of  program  testing  coverage  as  each  test  case  is  input 
to  the  system. 

2.2  PRELIMINARY  STEPS 

Before  the  source  text  to  be  verified  is  submitted  to  JAVS,  the  user 
should  take  certain  preliminary  steps: 

1.  The  source  text  should  be  compiled  by  a JOVIAL  compiler  to  confirm 
that  it  is  free  of  any  syntactical  errors. 

2.  The  program  to  be  tested  should  have  been  previously  executed  with 
test  data  necessary  to  ensure  proper  execution. 

3.  JAVS  text  identification  directives  should  be  inserted  in  the  source 
if  there  is  more  than  one  START-TERM  sequence  in  the  program. 

4.  JAVS  computation  directives  should  be  inserted  in  the  source  if  the 
performance  testing  capability  is  utilized. 

Both  types  of  JAVS  directives  (a  special  form  of  JOVIAL  comment)  are  described 
in  detail  in  the  JAVS  Reference  Manual  . The  JAVS  text  identification  directive 
is  used  to  assign  a unique  name  to  a JOVIAL  START-TERM  sequence  (program,  sub- 
program, or  COMPOOL) . If  no  text  directive  is  assigned  to  a START-TERM  sequence, 
a text  name  is  assigned  as  a default.  The  computation  directives  are 
used  to  make  assertions  about  the  behavior  of  the  program  and  to  verify  the 
value  of  specified  variables  without  altering  the  logic  of  the  program.  These 
directives  can  make  valuable  contributions  in  debugging  and  boundary  conditions 
testing.  It  is  suggested  that  the  user  acquire  some  familiarity  with  JAVS  before 
utilizing  the  computation  directives.  The  Reference  Manual  (Sec.  1.5)  describes 
their  capability  and  utilization. 
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The  following  sections  describe  the  recommeuJed  sequence  of  step 
executions  to  be  utilized  by  the  beginning  user.  Although  JAVS  Is  capable 
of  processing  very  large  JOVIAL  programs,  we  recommend  that  the  tester  select 
a modest  program  (several  hundred  JOVIAL  statements  or  less)  to  use  In  his 
first  experience  with  JAVS  processing. 

2.3  COMMAND  STRUCTURE 

The  user  directs  JAVS  processing  by  a set  of  commands.  There  are  four 
"macro"  commands  which  can  be  used  with  the  JAVS  3.0  overlay  program,  in 
addition  to  a variety  of  standard  commands.  Each  macro  command  expands  Into 
a set  of  commonly  used  standard  JAVS  commands.  While  both  types  of  commands 
can  be  used  together,  the  user  is  advised  to  be  aware  of  the  expansion  of 
the  macros  before  combining  commands.  Table  2.1  shows  the  relationship 
between  macro  commands,  standard  commands,  and  the  processing  tasks.  Sections 
3-8  describe  each  task,  as  well  as  the  appropriate  commands  to  use,  and  the 
process  of  executing  the  test  program  is  described  in  Sec.  6. 

All  commands  are  input  one  per  card.  Blanks  are  ignored,  so  the 
commands  are  free-form.  The  card  scan  ends  with  a period  or  with  the  end 
of  a card.  If  a command  requires  more  than  one  card,  a comma  must  appear 
at  the  last  non-blank  character  of  each  card  preceeding  the  continuation 
card.  Up  to  three  continuation  cards  may  be  used.  Each  command  consists  of 
a sequence  of  terms  separated  by  a comma  or  an  equals  sign. 


TABLE  2.1 

RELATIONSHIP  BETWEEN  COMMANDS  AND  TASKS 


Macro  Command 

Keyword 

Standard  Command 
Keyword 

Task 

BUILD  LIBRARY 

BASIC 

STRUCTURAL 

Syntax  analysis 
Structural  analysis 

PROBE 

INSTRUMENT 

Structural  and 

computation 

instrumentation 

DOCUMENT 

ASSIST 

PRINT 

DEPENDENCE 

Module  and  inter- 
module reports 

TEST 

ANALYZER 

Post-test  coverage 
and  trace  analysis 
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PRIMARY  ANALYSIS 


Prior  to  instrumentation,  documentation,  testing,  or  retesting,  a set 
of  primary  analyses  must  be  performed.  Syntax  analysis  is  performed  on  the 
JOVIAL  source  program,  transforming  it  into  a format  appropriate  for  storage 
on  a random-access  data  base  (library  file).  Using  the  information  on  the 
data  base,  structural  analysis  is  performed  on  the  executable  modules,  up- 
dating the  tables  in  the  data  base  library.  Structural  analysis  includes 
building  a directed  program  graph  which  is  the  basis  for  instrumentation  and 
testing  analyses.  The  subject  matter  of  this  section,  primary  analysis,  is 
shown  in  the  context  of  the  testing  process  in  Fig.  3.1. 

3 . 1 TASKS 

Syntax  analysis  consists  of  breaking-down  each  START-TERM  sequence  of 
the  JOVIAL  source  text  into  invokable  modules.  A data  base  library  is 
created  containing  internal  tables  representative  of  program  text,  statement 
descriptions  and  symbol  classification. 

Structural  analysis  adds  to  the  data  base  library  a description  of  pro- 
gram structure  in  terms  of  decision-to-decision  paths.  These  paths  represent 
a unique  and  systematic  ordering  of  all  decision  outways.  Figures  3.2  and 
3.3  illustrate  the  concept  of  DD-paths.  A DD-path  consists  of  all  the 
executable  statements  from  a conditional  ^^^ment  to  the  next  conditional 
statement.  Figure  3.2  shows  the  statement  membership  for  each  DD-path  in 
module  EXAMPL.  This  module  contains  12  DD-paths.  Below  each  DD-path  number 
(listed  across  the  page)  is  the  order  in  which  the  statements  are  placed  on 
each  DD-path.  For  example,  DD-path  2 consists  of  statements  15,  16,  29,  30, 
and  31  in  that  order. 

3.2  PRIMARY  ANALYSIS  INPUT 

JAY’S  requires  two  input  files  for  syntax  analysis:  the  JOVIAL  source 
program  in  BCD  mode  on  file  READER  (09)  and  the  JAVS  commands  in  BCD  mode  on 
file  COMMAC  (05) . If  the  source  program  contains  more  than  one  START-TERM 
sequence,  or  if  the  source  text  is  a C0MP00L  or  requires  a C0MP00L  to  compile, 
the  user  must  insert  a JAVS  text  identification  directive  as  the  first  state- 
ment. This  statement  is  described  in  Sec.  1.4  of  the  Reference  Manual  and 
is  shown  in  Figs.  3.2  and  3.4. 

Input  for  structural  analysis  are  the  JAVS  commands  and  the  data  base 
library  created  during  the  syntax  analysis. 

3.3  COMMANDS 

Primary  analysis  can  be  accomplished  by  the  single  JAVS  command: 

BUILD  LIBRARY  [=<name>]. 

This  command  expands  into  the  set  of  standard  commands  on  page  3-5. 
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BUILD 

LIBRARY 


JOVIAL  source  code  is  Input  for  processing  snd 
analysis.  A special  form  of  comment  (optional) 
Inserted  by  the  user  directs  JAVS  processing  for 
program  performance  analysis. 

JAVS  analyzes  the  code  and  generates  a directed 
graph  of  the  control  structure. 

The  possible  flows  through  the  program  ere 
determined.  All  pertinent  data  is  stored  In  a 
data  base  for  later  use.  Additional  or 
changed  source  code  causes  an  existing  data 
base  to  be  updated. 


Figure  3.1.  The  Role  of  Primary  Analysis  in  the  Testing  Process 
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".JAVS1EXT  EXAMPL  COMPUTE  ICOMPOLt" 
START 

PROC  EXAMPL  (AA«BB>* 

ITEM  AA  F S 
ITEM  BB  F* 

ARRAY  CC  2 2 F* 

BEGIN  BEGIN  1.0  1.0  END 

BEGIN  1.0  1.0  END  END 

BEGIN 

MONITOR  BB.  CCS 

IEE1TM  AA  LS  O.OS 

BB  * -AAS 

OR  IE  AA  EO  O.OS 

BEGIN 

BB  ■ O.OS 

EOR  1»0.1,1S 

BEGIN 

FOR  J=0.1,1S 
CC(Sl.JS)  > O.OS 
END 

RETURNS 

END 

OR1F  IS 
BB  = AAS 
END 

FOR  K=0»1.1S 
CC(SK.OS)  x B8/2.0S 
END 
TERHS 

MODULES  dEFINEO  IN  TEXT 

1 EXFMPL  {EXAMPL  ( 


Figure  3.4.  BASIC  Output 

CREATE  LIBARY=<name> . (default  name  is  TEST) 
START. 

BASIC. 

FOR  LIBRARY. 

STRUCTURAL. 

END  FOR. 

END. 


The  octions  taken  by  the  macro  command  (or  equivalent  set  of  standard 
commands)  is  to  initialize  the  JAVS  system  with  a library  whose  name  is 
<name>  (or  TEST  if  none  is  specified),  process  syntax  analysis  (BASIC)  re- 
moving JOVIAL  comment  statements,  and  perform  structural  analysis  for  all 
modules  on  the  newly  created  library. 

I here  are  several  BASIC  processing  options,  all  described  in  the 
Reference  Manual.  If  the  user  wishes  to  exercise  any  of  the  options,  to  delete 
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the  JOVIAL  comments  in  the  source  text  from  the  library,  or  to  perform  struc- 
tural analysis  on  a subset  of  the  modules,  he  cannot  use  the  BUILD  LIBRARY 
macro  command;  instead,  the  desired  sequence  of  BASIC  commands  must  be 
supplied.  Section  5 of  the  Reference  Manual  contains  sample  command  sets 
for  each  command  description. 

3.4  PRIMARY  ANALYSIS  OUTPUT 

The  main  output  is  a data  base  library  file  containing  the  source  text 
transformed  into  invokable  modules  and  tables  for  other  functional  processing 
and  reports.  Printed  output  consists  of  the  card  image  listing  of  the  JOVIAL 
source  code  (this  can  be  turned  off  with  a BASIC  option)  along  with  JAVS 
error  messages,  if  any,  and  a few  descriptive  lines  for  each  module  stating 
the  number  of  DD-paths  generated.  If  any  syntax  errors  are  printed  adjacent 
to  the  offending  source  text  line,  they  should  be  scrutinized.  A complete 
list  of  JAVS  errors  is  in  Appendix  B of  the  Reference  Manual.  Some  errors 
will  require  source  code  changes  before  further  processing,  and  some  errors 
are  syntactical  warnings. 

Figure  3.4  shows  the  syntax  analysis  output  and  Fig  3.5  shows  struc- 
tural analysis  output  for  module  EXAMPL. 


jj 

JOVIAL  AUTOMATED  VERIFICATION  SYSTEM  SECONDARY  MODULE  ANALYSIS  ••• 

MODULE  EXAMPL  > OF  JAVSTEXT  <EX AMPL  >. 

MOnuLE  DEPENDENCE  TABLE  CONSTRUCTED. 

STATEMENT  DESCRIPTOR  BLOCKS  UPDATED. 

DD-PATH  TABLE  CONTAINS  12  ENTRIES. 


Figure  3.5.  STRUCTURAL  Output 
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COMMAND  SUMMARY 


The  subset  of  JAVS  commands  which  will  enable  the  first-time  user  to 
process  his  source  code  are  summarized  in  Table  9.1.  The  command  streams  in 
Table  9.2  show  the  natural  order  of  processing  and  a typical  selection  of 
commands.  Instrumentation,  activity  2 in  Table  9.2,  is  shown  as  a separate 
activity  so  that  the  user  can  obtain  the  statement  numbers  needed  by  the 
PROBI  commands.  Instrumentation  can  be  performed  as  part  of  the  first 
activity  following  the  BUILD  LIBRARY  operation  if  the  user  wishes  to  manually 
insert  (through  a text  editor)  the  necessary  invocations  to  the  PROBI  data 
collection  routine. 


The  rules  for  JAVS  macro  command  usage  and  the  default  option  values 
are  described  in  Appendix  B.  For  a complete  description  of  all  JAVS  commands 
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TABLE  9.1 
COMMAND  SUMMARY 


. 

| 


f 

II 


TASK 

COMMAND 

OPTIONS 

U) 

Perform  syntax  and 
structural  analyses 
create  data  base 
library 

BUILD  LIBRARY 

-<llbrary  naae>. 

(2) 

Generate  reports  for 
documentation 

DOCUMENT 

,JAVSTEXT  ■ <text  namc>, 
MODULE  - <name-l > , . . . , 
<name-n> . 

(3) 

Insert  test  case 
Initiation 

PROBI, STARTTEST  - 
<module  nanic>, 

<text  name>, 
<statement  no.> 

,<test  case  name>, 
<traclng  level>. 

<*> 

Insert  test 

termlnat Ion 

PROBI ,STOPTEST  - 
<module  name>, 

<text  name>, 
statement  no.>. 

(5) 

Instrumentation 

PROBE, JAVr.l  i XT  - 
<text  narif  •• 

.MODULE  - * name-1 > 

<name-n> . 

(6) 

Post-test  analysis 

TEST 

.MODULE  • <naroe-l> , . . . , 
<name-n> . 

(7) 

Retesting 

AS SI ST, REACH INC  SET, 
<target  > 

,<initial>, ITERATIVE, 
PICTURE 

TABLE  9.2 

SAMPLE  COMMAND  SETS 

ACTIVITY 

COMMANTS 

1 

BUILD  LIBRARY. 

DOCUMENT . 

2 

OI.D  LIBRARY  - TEST. 

START. 

PRORl.STARTTFST  - <ihodul(  -amo, 

<JAVSTEXT  name> , ^statement  no.>. 

PROBI .STOPTESI  m < module  name>, 

<JAVSTFXT  n»mc>,'s,8»pmcnt  no  >. 

PROBE, JAVSTF.XT  * <JAVSTFXT  nnree> . 

3 

Perform  Test  Execution 

4 

OLD  LIBRARY  - TEST. 

START. 

ANALYZER, MODLST. 

ANALYZER,  DDPATI1S. 

TEST. 

Q _ 9 


* 


JAVS  COMMANDS  (DEFAULTS  UNDERLINED) 

STEP 

ALTER  LIBRARY  = <libname". 

(Universal) 

ANALYZER. 

ANALYZER 

ANALYZER, ALL. 

ANALYZER 

ANALYZER, ALL  MODULES . 

ANALYZER 

ANALYZER, CASES  = <number''. 

ANALYZER 

ANALYZER, DDPATHS. 

ANALYZER 

ANALYZER. DDPTRACE. 

ANALYZER 

ANALYZER , FACTOR  = --percent-increase''. 

ANALYZER 

ANALYZER, HIT. 

ANALYZER 

ANALYZER. MODEST. 

ANALYZER 

ANALYZER , MODTRACF . 

ANALYZER 

ANALYZER, MODULE  = < name- 1 > ,<name-2>  , . . . ,<-name-n>  . 

ANALYZER 

ANALYZER, NOTH IT. 

ANALYZER 

ANALYZER, SUMMARY. 

ANALYZER 

ANALYZER, TIME. 

ANALYZER 

ASS  1ST  .CROSSREF  . JAYSTEXT  = <text-narae-l"> . < text-nane-2'  ..... 

< text-name-n'' . 

ASSIST 

AS  S I ST , CROSSREF , LI B RARY . 

ASSIST 

ASS  I ST, PICTURE. 

ASSIST 

ASSIST, PICTURE-;  .CONTROL);  , NOSWITCH}. 

ASSIST 

ASS  I ST , REACHING  SET , •■  number- to'-  { , ^number- f rom'  ■ 

{ .PICTURE -r  .ITERATIVE)). 

ASSIST 

ASS  1 ST , STATEMENTS . 

ASSIST 

BAS  I C . 

BASIC 

BASIC, CARD  IMAGES  = ON /OFF. 

BASIC 

BASIC, COMMENTS  = ON/OFF. 

BASIC 

BASIC, DEFINES  = ON/OFF. 

BASIC 

BUILD  L I BRARY  = < libra rv  name>  . 

CREATE  LIBRARY  = <libname>. 

BASIC, 

STRUCTURAL 

(Universa 1 ^ 

* 


-a.- - - — - 


- 


JAVS  COMMANDS  (DEFAULTS  UNDERLINED) 


STEP 


1 


DEPENDENCE, BANDS. 

DEPENDENCE, BANDS  = <number>. 

DEPENDENCE, GROUP, AUXLIB. 

DEPENDENCE, GROUP, I IBRARY. 

DEPENDENCE, GROUP, MODULES  = <name-l> , <name-2> , . . . , <name-n> . 
DEPENDENCE, PRINT, INVOKES. 

DEPENDENCE .SUMMARY . 

DEPENDENCE, TREE. 

DESCRIBE  = ON/OFF. 

DOCUMENT { , JAVSTEXT=<  text-name>{ ,MODULE=<name-I> , . . . }} . 


DEPENDENCE 

DEPENDENCE 

DEPENDENCE 

DEPENDENCE 

DEPENDENCE 

DEPENDENCE 

DEPENDENCE 

DEPENDENCE 

(Universal) 

ASSIST, 
DEPENDENCE, 
(Universal ) 


END. 

END  FOR. 

FOR  JAVSTEXT. 

FOR  LIBRARY. 

FOR  MODUI  E = <r.ame-l>  , <name-2>  , . . . , <name-n>  . 

INSTRUMENT. 

INSTRUMENT, MODE  = INVOCATION /DDPATHS /DIRECT IVES /FULL. 
INSTRUMENT , PROBE , DDPATH  = <probe-name> . 

INSTRUMENT, PROBE, MODULE  = <invocation-name> . 

INSTRUMENT, PROBE,  TEST  *=  <test-name>. 

INSTRUMENT , STARTTEST  = <modname> , < textname> , <s tmt . no . > 
{ i<TESNAM> } { ,<TFLAG> } . 

INSTRUMENT, STOPTEST  = <modname> , < textname> , 

<stmt.  no.>. 

JAVSTEXT  = <text-name>. 

MERGE. 

MODULE  = <name>. 

OLD  LIBRARY  = <libname>. 


(Universal) 
(Universal ) 

(Universal) 

(Universal) 

(Universal) 

INSTRUMENT 

INSTRUMENT 

INSTRUMENT 

INSTRUMENT 

INSTRUMENT 

INSTRUMENT 

INSTRUMENT 


(Universal  1 

(Uni ver > 1 1 
(Universa 
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(Univer 
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UNCLASSIFIED 
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JAVS  COMMANDS  (DEFAULTS  UNDERLINED) 

STEP 

I’RINT , DDP  . 

(Universal) 

PRINT, DDPATHS. 

(Universal) 

PRINT, DMT. 

(Universal) 

PRINT, JAVSTEXT  = text-name-l>,  INSTRUMENTED  = ALL. 

(Universal) 

PRINT, JAVSTEXT  = <text-name>, INSTRUMENTED  = <name-l>, 
<name-2>, . . . , <name-n>. 

(Universal) 

PRINT, JAVSTEXT  = <text-name>. 

(Universal) 

PRINT, MODULE. 

(Universal) 

PRINT, SB. 

(Universal) 

PRINT, SDB. 

(Universal) 

PRINT, SLT. 

(Universal) 

PRINT, STB. 

(Universal) 

PROBE,  JAVSTEXT  = <text-name>{ .MODULE  = <name-l> , . . . } . 

INSTRUMENT, 

(Universal) 

PROB l , STARTTEST  = <modname > , < textname> , <s tmt . no . > 

INSTRUMENT, 

{ ,tesnamH,tflag}. 

(Universal) 

PROBI , STOPTEST  = <modname> t < textname> , <stmt . no.>. 

INSTRUMENT, 

(Universal) 

PUNCH, JAVSTEXT  = <text-name>. 

(Universal) 

PUNCH, JAVSTEXT  = < text-name> , INSTRUMENTED  = ALL. 

(Universal ) 

PUNCH .JAVSTEXT  = < text-name> , INSTRUMENTED  = <name-l>, 
<name-2> , . . . , <name-n> . 

(Universal) 

PUNCH, MODULE. 

(Universal) 

START. 

(Startup) 

STRUCTURAL. 

STRUCTURAL 

STRUCTURAL, PRINT  - SUMMARY /DEBUG. 

STRUCTURAL 

TEST!, MODULE  = <name-l>,<name-2>, . . .<name-n>} . 

ANALYZER, 

(Universal) 

B.l  INTRODUCTION 

To  facilitate  the  use  of  JAVS,  four  new  commands  were  added  to  the 
existing  set  of  processing  commands.  These  "macro"  commands  combine  the 
most  commonly  used  commands  from  the  standard  set.  The  macro  commands  may 
be  used  one  at  a time,  all  together,  or  in  combination  with  the  standard 
set  of  commands.  The  combination  of  commands  requires  understanding  the 
expansion  of  commands  which  each  macro  generates;  thus,  the  user  is  urged 
to  review  Sec.  B.2  carefully.  The  four  macro  commands  are: 


1.  BUILD  LIBRARY  |-<name>). 

2.  PROBE  .JAVSTEXT  - <text-name>  [ .MODULE  » <name-l">,  < name -2s, 

. ..<name-n>]  . 

3.  TEST(, MODULE  - <name-l>,  <name-2>,  ....  <name-n>l. 

4.  DOCUMENT  |, JAVSTEXT  - <text-name> [ .MODULE  - <name-l>,  <name-2>, 

. . . <name-n> ] ] . 

Brackets  ||  indicate  optional  information.  Each  option  generates  a 
different  set  of  standard  commands. 

B.2  EXPANSION  OF  MACRO  COMMANDS 

Unless  the  user  supplies  the  library  identification  and  start  commands, 
the  first  occurrence  of  a macro  command  in  the  command  set  generates  the 
standard  commands: 

CREATE  LIBRARY  - TEST. 

START . 
or 

OLD  LIBRARY  - TEST. 

START. 

All  macros  except  BUILD  LIBRARY  generate  the  OLD  LIBRARY  command. 

B . 2 . 1 Syntax  and  Structural  Analysis 

BUILD  LIBRARY.  generates  commands: 

CREATE  LIBRARY  - TEST. 

START . 

BASIC. 

FOR  LIBRARY. 

STRUCTURAL. 

END  FOR. 


B-2 


1 


BUILD  LIBRARY  - <name>.  generates  commands: 

CREATE  LIBRARY  - <name>. 

START. 

BASIC.  * 

FOR  LIBRARY. 

STRUCTURAL. 

END  FOR. 


B.2.2  Documentation  Reports 

DOCUMENT . generates  commands: 

ASSIST,  CROSSREF,  LIBRARY. 

DEPENDENCE.  GROUP,  LIBRARY. 

DEPENDENCE,  GROUP,  AUXLIB. 

DEPENDENCE,  SUMMARY. 

FOR  LIBRARY. 

PRINT, MODULE. 

DEPENDENCE,  BANDS- 5 
DEPENDENCE,  PRINT,  INVOKES. 

END  FOR. 

DOCUMENT,  JAVSTEXT  = <text  name> . generates  commands 

ASSIST,  CROSSREF,  LIBRARY. 

DEPENDENCE,  GROUP,  LIBRARY. 

DEPENDENCE,  GROUP,  AUXLIB. 

DEPENDENCE,  SUMMARY. 

JAVSTEXT*  < text  name>. 

FOR  JAVSTEXT. 

PRINT,  MODULE. 

DEPENDENCE,  BANDS  = 5. 

DEPENDENCE , PRINT , INVOKES . 

END  FOR. 


DOCUMENT,  JAVSTEXT  - <text-name>,  MODULE  - <name-l>, 
<name-n> . generates  commands: 


ASSIST,  CROSSREF,  LIBRARY. 

DEPENDENCE,  GROUP,  LIBRARY. 

DEPENDENCE,  GROUP,  AUXLIB. 

DEPENDENCE,  SUMMARY. 

JAVSTEXT  - <text  name> . 

FOR  MODULE  - <name-l>,  <name-2>,  ...,  <name-n>. 
PRINT,  MODULE. 

DEPENDENCE,  BANDS  - 5. 

DEPENDENCE,  PRINT,  INVOKES. 

END  FOR. 


• • • » 
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B . 2 . * 1 11st  r umen t at  Ion 

PROBE^  JAVSTEXT  = <text  name  - . generates  commands: 

JAVSTEXT  = <text  name> . 

FOR  JAVSTEXT. 

I NSTRUMENT . 

END  FOR. 

PUNCH,  JAVSTEXT  = -text  name> , INSTRUMENTED  = ALL. 

PROBE , JAVSTEXT  = -.text  name>,  MODULE  = ..name-1  >,  <name-2>,  .... 
<name-n>.  generates  commands: 

JAVSTEXT  = <text  nume>. 

FOR  MODULE  = <name-l>,  ....  <name-n>. 

INSTRUMENT. 

END  FOR. 

PUNCH,  JAVSTEXT  = -text  name>,  INSTRUMENTED  * -name-1", 

....  <name-n> . 


H.J.J  lest  Boundary  Insertion  (, quasi -macro  cqmnuinds) 

In  order  to  identify  test  cases  and  control  the  recording  of  data  on 
the  AUDIT  file,  the  user  must  supply  invocations  to  the  data  collection 
routine,  PROBI.  The  invocations  can  be  manually  inserted  prior  to  Test 
Execution,  or  they  can  be  automatically  inserted  during  instrumentation. 

The  PROBI  commands  cause  JAVS  to  insert  an  invocation  to  PROBI  for 
identifying  a new  test  case  or  terminating  the  test.  The  commands  are  of 
the  form: 

PROBI , STARTTEST  = <m-name>,  <t-name>,  <no . >1 , <TESNAM> , <TFLAG>  } . 
PROBI , STOPTF.ST  = <m-name>,  <t-name>,  <no.>. 

where 


m-name 
t name 
no. 
TESNAM 
IE  I.  AO 


module  name 
.lavs text  name 
statement  number 

test  case  identifier  DEFAULT  * 8H(CASE  ) 
tracing  level  DEFAULT  = 2 
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JAVS  FILES 


i 

tj 


INTRODUCTION 


C.l 

The  files  used  in  JAVS  processing  are  listed  in  Table  C.l  together 
with  important  characteristics  about  each  file.  On  systems  which  allocate 
files  by  number  (e.g.,  GCOS)  the  file  number  is  used;  on  those  which  allocate 
the  file  by  name  (e.g.,  GOLETA) , the  file  name  is  used.  The  data  structure 
column  indicates  the  contents  of  the  file.  The  mode  indicates  how  JAVS 
references  the  file.  The  storage  form  and  record  format  describe  how  the 
data  is  recorded.  The  recommended  allocation  suggests  an  appropriate  type 
of  system  file,  keeping  in  mind  that  random  files  must  be  on  direct  access 
devices  and  sequential  files  may  be  on  either  direct  access  devices  or  serial 
devices.  The  usage  indicates  how  each  file  is  utilized  for  different  types 
of  JAVS  processing. 

The  JAVS  Reference  Manual^  contains  a detailed  description  of  file  usage 
for  each  processing  step. 

C . 2 RANDOM  FILES 

LIBOLD  and  LIBNEW  are  used  for  the  JAVS  data  base  library.  L1BWSP 
is  always  used  for  working  space.  On  all  of  these  random  files,  the  JAVS 
Storage  Manager  allocates  space  for  each  JAVS  table  in  contiguous  groups 
of  500  words  called  "fragments."  Each  file  is  treated  internally  as  a word- 
addressable  file,  although  it  may  be  recorded  in  another  form  (e.g.,  as 
fixed-length  records).  The  wrapup  summary  at  the  end  of  each  JAVS  execution 
contains  the  current  size  for  each  of  these  files. 

C . 3 SEQUENTIAL  FILES 

COMMAN,  COMMAC  and  COUAUX  are  used  for  JAVS  commands.  COMMAC  and 
COMMAN  have  a card  image  record  for  each  command  line;  COllAUX  (always 
shorter  than  COMMAN)  is  used  to  store  the  commands  within  an  iteration 
sequence.  COMMAN  and  COMMAC  must  always  be  allocated  for  any  processing 
step.  COMAUX  must  be  allocated  whenever  any  FOR  command  is  used. 

LOUT  contains  all  JAVS  reports  destined  for  the  line  printer.  The 
number  of  records  on  LOUT  depends  on  the  number  and  types  of  reports  produced. 
The  example  reports  in  the  JAVS  Reference  Manual  are  useful  in  estimating 
the  size  of  LOUT.  LOUT  is  always  needed  in  any  processing  step. 

LPUNCH  contains  instrumented  (or  non-instrumented)  source  (in  card  image 
form)  destined  for  the  JOVIAL  compiler.  The  card  image  source  can  be  written 
at  any  time  as  long  as  it  was  saved  on  the  database  library.  Usually,  LPUNCH 
is  written  during  the  instrumentation  activity. 

AUDIT  contains  the  Test  Execution  probe  data.  It  is  possible  to  record 
three  types  of  records  on  AUDIT.  The  types  of  records  actually  recorded  can 
be  controlled  during  INSTRUMENT  processing  by  the  MODE  option  and  during 
Test  Execution  by  an  argument  value  to  PROBI.  Clearly,  for  a fully  instru- 
mented program  with  complete  tracing  and  a large  number  of  DD-path  executions, 
the  number  of  records  on  AUDIT  can  become  very  large  (to  say  nothing  about 
the  added  processing  time).  AUDIT  is  used  in  Test  Execution  and  ANALYZER. 
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FILES  USED  IN  JAVS  PROCESSING 


... 


I 


In  general  there  is  no  way  to  estimate  the  size  of  the  AUDIT  file. 
It  depends  on  the  execution  behavior  of  the  program  being  analyzed 

READER  contains  the  JOVIAL  source  (In  card  Image  form)  to  be 
by  JAVS.  READER  is  used  bv  the  Syntax  Analvzer  (BASIC). 


analyzed 
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D.l  PERFORM  SYNTAX  AND  STRUCTURAL  ANALYSES 


$ 

IDENT 

<user1d>,<user  name>,<acc't.  no.> 

$ 

USERID 

<userid>$  password  > 

$ 

SELECT 

BFCBGRC1/JAVSXQ 

$ 

PRMFL 

02,  R/W,R, <user1d>/<l ibrary  file  name> 

$ 

PRMFL 

09,  R,S,<userid>/<source  file  name> 

BUILD 

LIBRARY. 

$ 

ENDJOB 

4 


« 


I 


I 


! 


Notes : 

* (1)  The  LIMITS  control  card  imbedded  in  the  SELECT  stream 

specifies  .99  CP  hour  and  40,000  lines  of  output.  The 
user  can  modify  these  limits  by  placing  the  following 
control  card  before  the  JAVS  command: 

$ LIMITS  <time> ,53K,-5K,<1 ines> 

* 

(2)  To  obtain  the  JAVS  enhanced  listing  for  each  module  during 
this  activity,  follow  BUILD  LIBRARY  with: 

FOR  LIBRARY. 

PRINT, MODULE. 

ENO  FOR. 


(3)  To  obtain  JAVS  documentation  reports  within  the  same 
activity,  follow  BUILD  LIBRARY  with: 

DOCUMENT. 


(4)  The  default  library  name  is  TEST.  The  user  may  provide  any 
library  name  (up  to  eight  characters)  but  in  doing  so  must 
provide  the  library  identification  and  start  commands  in 
subsequent  JAVS  processing  jobs  to  reflect  the  non-default 
library  name.  See  page  B--2  for  more  information. 
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D.2  OBTAIN  JAVS  DOCUMENTATION  REPORTS 


s 

IDENT 

<userid>,<user  name>,<acc ' t.  no.> 

i 

USERID 

<userich$<password> 

S 

SELECT 

BFCBGRC1 /JAVSXQ 

$ 

PRMFL 

01,  R,R,<userid>/<! ibrary  file  name> 

DOCUMENT . 

$ 

ENDJOB 

Notes • 

(L)  The  LIMITS  control  card  imbedded  in  the  SELECT  stream 
specifies  .99  CP  hour  and  40,000  lines  of  output.  The 
user  can  modify  these  limits  by  placing  the  following 
control  card  before  the  JAVS  command: 

$ LIMITS  <time>,53K,-5K,<l ines> 


(2)  To  obtain  the  JAVS  control  flow  picture  for  each  module, 
in  addition  to  the  other  documentation  reports,  follow 
the  DOCUMENT  command  with: 

FOR  LIBRARY. 

ASSIST, PICTURE. 

END  FOR. 

or  precede  the  DOCUMENT  command  with: 

OLD  LIBRARY  = TEST/ 

START. 

FOR  LIBRARY. 

ASSIST, PICTURE. 

END  FOR. 


The  default  library  name  is  TEST.  The  user  may  provide  any  library  name 
(up  to  eight  characters)  but  in  doing  so  must  provide  the  library  identifi- 
cation and  start  commands  in  subsequent  JAVS  processing  jobs  to  reflect  the 
non-default  library  name.  See  page  B-2  for  more  information. 


D.  3 INSTRUMENT  A START -TERM  SEQUENCE  (JAVSTF.XT) 


$ 

IDENT 

<userid'>,<user  name>,<acc't.  no.> 

$ 

USERID 

<userid>$<password> 

$ 

SELECT 

BFCBGRC1 /JAVSXQ 

$ 

PRMFL 

01,  R,R,<userid>/<l ibrary  file  name> 

$ 

PRMFL 

07  W,S,<userid>/<instrumented  source  file  name> 

OLD 

LIBRARY  = 

TEST. ’ 

START. 

PROBI.STARTTEST  = <options>. 
PROBI.STOPTEST  » <options>. 
PROBE, JAVSTEXT  = <text  name>. 
$ ENDJOB 


Notes : 

(1)  See  D. 2 note  (I) . 

(2)  Library  identification  and  start  commands  are  required 
for  PROEI  commands. 

(3)  To  manually  insert  the  PR0B1  test  case  boundary  calls, 
remove  the  first  four  commands. 

(4)  To  obtain  a listing  of  the  instrumented  modules,  follow 
the  PROBE  command  with: 

PRINT, JAVSTEXT  = <text  name> , INSTRUMENTED  = ALL. 


This  job  stream  does  not  save  the  probed  code  on  the  database  library. 

4*  4* 

The  default  library  name  is  TEST.  The  user  may  provide  any  library  name 
(up  to  eight  characters)  but  in  doing  so  must  provide  the  library  identifica- 
tion and  start  commands  in  subsequent  JAVS  processing  jobs  to  reflect  the 
non-default  library  name.  See  page  B-2  for  more  information. 
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D.A  INSTRUMENT  A START-TERM  SEQUENCE  (.IAVSTEXT) 


$ 

$ 

$ 

ALTER 

START. 

PROBl, 

PROBI, 

PROBE . 

$ 


IDENT  vuserld^ ,^user  name^ ,vacc 1 t . no»> 

USERID  vuserid'jvpassword' 

PRMEL  H*,R,R, BFCBGRC1 /JAVSXQ 

PRMFL  02,  R/W,R,KUser1d^/vl1brary  file  name^ 

PRMTL  07,  W,S,vuser1d^/> instrumented  source  file  name^ 

LIMITS  v 1 1mes . !)JK, -5K, vl  i nes*» 

L IBRARY  =■  TEST,  t t 


STAR1 TEST  « * opt  ions-. 
STOPTEST  ■ < options'. 

JAVSTEXT  * text  r.ame>, 
ENDJOB 


See  D . I notes . 


this  Job  st  team  stives  t !\o  probed  rode  on  the*  d.*it  abase*  library  whleh 
can  substunt  lallv  Increase*  the  library's  t lie*  size. 

' The  default  library  name  Is  TEST.  The  user  may  provide  anv  library  name 
(up  to  eight  eharaet ersl  but  in  doing  so  must  provide  the  library  Identifi- 
cation and  start  commands  in  subsequent  dA\'S  processing  jobs  to  tolled  the 
non-de fault  library  name.  See  page*  R-2  !e>r  me>re*  Information. 


D. 5 COMPILE  INSTRUMENTED  SOURCE  TEXT 


$ 

I DENT 

<userid>,<user  name>,<acc't.  no.> 

$ 

USERID 

<userid>$<password> 

$ 

L0WL0AD 

$ 

OPTION 

FORTRAN 

$ 

JOVIAL 

N0PT.NDECK.NAME/PRP00L/ .P00L0U/JP/ 

$ 

FILE 

JP.X1S.2L 

$ 

SELECT 

BFCBGRC 1 /COMPILER 

$ 

LIMITS 

1.49K 

$ 

SELECT 

BFCBGRC2/PRP00L 

$ 

JOVIAL 

POOL IN/JP{ .user  C0MP00LS}/ ,N0PT, 

$ 

ETC 

NAME/<name>/ 

$ 

FILE 

JP.X1R.2L 

$ 

SELECT 

BFCBGRC1 /COMPILEB 

$ 

LIMITS 

<time>,<size>, ,<1 ines> 

$ 

PRMFL 

S*,R,S,<userid>/<instrumented  source  file> 

$ 

PRMFL 

C*,W,S,<usend>/<instrumented  object  file^ 

• 

user  C0MP00L  perm  files 

$ 

ENDJOB 

Notes : 

(1)  Currently  the  backup  JOCIT  compiler  (version  042275)  is  being 
used.  If  the  user  wishes  to  use  another  version  of  the  JOCIT 
compiler,  the  JAVS  data  collection  routines  must  be  recompiled 
using  the  same  version. 

(2)  The  CP  time  in  the  second  LIMITS  control  card  should  be 
approximately  1.5  times  the  CP  time  required  to  compile  the 
uninstrumented  text. 

(3)  The  core  size  in  the  second  LIMITS  control  card  should  be 
approximately  1.25  times  the  size  required  to  compile  the 
uninstrumented  text. 


* 
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D.6  TEST  EXECUTION  AND  POST -TEST  ANALYSIS 


$ 

I DENT 

<userid>,<user  name>,<acd't.  no.> 

$ 

USERID 

<userid>$<password> 

$ 

LOWLOAD 

$ 

OPTION 

fortran 

$ 

SELECT 

BFCBGRC1 /JPROBESX 

$ 

SELECT 

<userid>/<instrumented  object  f i 1 e> 

$ 

SELECT 

BFCBGRC1/EXECUTEB 

$ 

LIMITS 

<time^,<size>, ,<1  ines> 

$ 

PRMFL 

08,  W,S,<userid>/<AUDIT  f i 1 e> 

• 

user  files 

and  data 

$ 

SELECT 

BFCBGRC1 /JAVSXQ 

$ 

LIMITS 

<time>,  53K,-5k,<1 ines> 

$ 

PRMFL 

01,  R,R,<userid>/<l  ibrary  file> 

$ 

PRMFL 

08,  R,S,<userid>/<AUDIT  f i 1 e> 

OLD  LIBRARY  = TEST.+ 

ctadt 

ANALYZER, MO DLST. 
ANALYZER, DDPATHS. 
TEST. 

$ ENDJOB 


Notes: 

(1)  To  obtain  a printed  listing  of  the  input  data,  if  the  data 
were  on  a perm  file,  insert  the  following  control  cards 
before  selecting  JAVSXQ: 

$ CONVER 

$ INPUT  NMEDIA 

$ PRMFL  IN,R,S,<userid>/<data  file> 

$ PRINT  OT 

(2)  The  EXECUTEB  select  stream  supplies  JOVIAL  system  routines 
used  by  the  backup  JOCIT  compiler.  This  can  be  changed 

to  EXECUTE  if  all  software  modules  were  compiled  using 
a newer  version  of  JOCIT. 

(3)  Additional  instrumented  files  can  be  loaded. 

(4)  In  an  overlay  environment,  JPROBESX  must  be  loaded  in 
the  main  link. 

(5)  The  AUDIT  file  can  be  a scratch  disk  file  or  magnetic 
tape,  instead  of  a perm  file. 


The  default  library  name  is  TEST.  The  user  may  provide  any  library  name 
(up  to  eight  characters)  but  in  doing  so  must  provide  the  library  identifi- 
cation and  start  commands  in  subsequent  JAVS  processing  jobs  to  reflect  the 
non-default  library  name.  See  page  B-2  for  more  information. 
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D.7  RETEST  INC.  ASSISTANCE  (REACHING  SETS) 


$ IDENT  <userid',^user  name  • ,*-acc ' t . no.> 

$ USERID  * userid  $• password' 

$ SELECT  BFCBGRC1 /JAVSXQ 

$ PRMFL  01,  R,R,^userid'/<l ibrary  file  name' 

OLD  LIBRARY  = TEST. • 

START. 

ASSIST, RE ACHING  SET, -target', (options!. 


ENOJOB 


The  default  library  name  Is  TEST.  The  user  may  provide  any  library  name 
(up  to  eight  characters)  but  in  doing  so  must  provide  the  library  identifi- 
cation and  start  commands  in  subsequent  JAVS  processing  lobs  to  reflect  the 
non-default  library  name.  See  page  B-2  for  more  information. 
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In  the  event  that  the  user  wishes  to  modify  the  control  cards  nested  in 
the  two  JAVS  SELECT  control  cards,  the  expansions  are  as  follows: 

I 


$ SELECT  BFCBGRC1 /JAVSXQ  contains 

$ PROGRAM  RLHS 

$ PRMFL  H* ,R ,R ,BFCBGRC1 /HSTAR/JAVSHS 

$ LIMITS  99, 53K.-5K, 40000 

$ FILE  03.X3RJ0R 

$ FILE  10.C1R.1L 

$ FILE  04 ,X4R,2L 

$ FILE  02,X2R,20R 


$ SELECT  BFCBGRC1 / JPR0BESX 

$ SELECT  BFCBGRC2/BPRCMPL 

$ SELECT  BFCBGRC2/BPR0BE 

$ SELECT  BFCBGRC2/BPR0BI-X 

$ SELECT  BFCBGRC2/BPR0BM-X 

$ SELECT  BFCBGRC2/BPR0BD-X 


i 
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TABLE  E.l 


FILE  SIZE  ESTIMATE  N 


File  # 


File 


01,  02 

Library 

15-20  1 links/module 

(LIBOLD, 

300  llinks/1000  source  statements 

L1BNEVI) 

4-5  times  source  file  size  (llinks) 

03 

LIBWSP 

10  llinks 

04 

COMAUX 

2 llinks 

07 

LPUNCH 

( instrumented 
source) 

8 llinks/module 

100  llinks/1000  source  statements 

2 times  uninstrumented  source  file  size  (llinks) 

Inst  rumented 

object  file 

.3  times  LPUNCH  (llinks) 

2 times  uninstrumented  object  file  size 

08 

AUDIT 

Minimum  size  (no  execution  tracing'  is: 

(number  of  probed  DD-paths  x numbet  of 

test  cases  x .2  llinks) 

Maximum  size  is  dependent  upon  execution 

behavior  and  level  of  tracing 

08 

READER 

.04  llinks/souree  card 

10 

COMMAS 

1 llink 

* ' ' ' 

These  estimations  are  derived  from  test  lap,  the  SAC  Force  Management 
System. 


Informat  ion 
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TABLE  E. 2 

CP  Time  Estimation 


* 


rap 


Task/Command 
BUILD  LIBRARY 
DOCUMENT 
PROBE 

Compile  instrumented  code 
Test  Execution 

TEST* 


CP  Hour/Module 
.010 
.006 
.005 
.001 


CP  Hour/ 

1000  Statements 

.17 

.1 

.07 

.02 


1.5  times  execution  time  for  uninstrumented 
program 

3-6  times  Test  Execution  time 
.01  CP  hour /module 


! 

I 

■ 

I 

Very  rough  estimates,  since  TEST  CP  time  depends 
heavily  on  the  size  of  the  AUDIT  file. 
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appendix  f 

JAVS  INSTALLATION  REQUIREMENTS 


i 
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TABLE  F.  1 


DATE 

VERSION 

COMPUTER 

OPERATING  SYSTEM 
COMP  I LER 

NON-STANDARD  FEATURES 
CONFIGURATION 


JAVS  INSTALLATION  AT  RADC 


June  1978 
3.0  overlay 
HIS  6180 

GCOS  version  C update  3 
JOCIT  JOVIAL/ .13  version  042275 
JOVIAL  MONITOR,  FORTRAN  random  I/O 
batch,  linked 


PROCESSING  CORE  REQUIREMENTS: 


Program  File 


HSTAR/ JAVSHS 

JPROBESX 

JAVSXQ 


Type  Load  Size  Process 

H*  5 3K  Complete  JAVS  overlay 

select  4K  Test  Execution 

select  select  H*  and  work  files 


FILES: 


Numbe  r 

Name 

Allocat ion 

Usage 

Description  (1) 

1 

LI BOLD 

save 

R/V! 

300  W/ records,  R,  U,  F 

2 

LIBNEW 

save 

R/W 

300  W/ record,  R,  U,  F 

3 

LIBWSP 

scratch 

R/W 

300  W/ record,  r,  U,  F 

4 

COMAUX 

scratch 

R/W 

BCD,  card  image 

5 

COMMAC 

card  reader 

R 

system  input,  BCD 

6 

LOUT 

printer 

w 

system  output 

7 

LPUNCH 

compile 

W 

BCD,  card  image 

8 

AUDIT 

save 

R/W 

Binary,  8 W/record 

9 

READER 

source 

R 

BCD,  card  image 

10 

COMMAN 

scratch 

R/W 

BCD,  card  image 

Note  : 

(1)  W = words,  R = random,  U = unpartioned,  F = fixed  length 
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TABLE  F. 2 


JAVS  INSTALLATION  AT  SAC  HEADQUARTERS 


DATE 

VERSION 

COMPUTER 

OPERATING  SYSTEM 
COMPILER 

NON-STANDARD  FEATURES 
CONFIGURATION 


July  1978 
3.0  overlay 
HIS  6180 
WWMCCS 

JOCIT  JOV1AL/J3  version  042275 
JOVIAL  MONITOR,  FORTRAN  random  I/O 
batch,  linked 


PROCESSING  CORE  REQUIREMENTS: 


Program 

File 

Type  Load  Size 

Process 

HSTAR  /JAVSHS 

H* 

5 3K 

Complete  JAVS  overlay 

JPROBESX 

select 

4K 

Test  Execution 

JAVSXQ 

select 

select  H*  and  work  files 

FILES: 

Number 

Name 

A I locat ion 

U s ap,e 

Description  (1) 

l 

LI  BOLD 

save 

R/W 

300  W/records,  R,  U,  F 

2 

LIBNEW 

save 

R/W 

300  W/record,  R,  U,  F 

3 

LIBWSP 

scratch 

R/W 

300  W/record,  R,  U,  F 

4 

COMAUX 

scratch 

R/W 

BCD,  card  image 

5 

COMMAC 

card  reader 

R 

system  input,  BCD 

6 

LOUT 

printer 

W 

system  output 

7 

LPUNCH 

compile 

W 

BCD,  card  image 

8 

AUDIT 

save 

R/W 

Binary,  8 W/record 

9 

READER 

source 

R 

BCD,  card  image 

10 

COMMAN 

scratch 

R/W 

BCD,  card  image 

* 


Note : 

(1)  W « words,  R « random,  U - unpartioned,  F » fixed  length. 
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Prepare  source  code: 


a.  Insert  JAVSTEXT  directive  as  the  first  statement  of  each  START-TERM 
sequence . 

If  the  START-TERM  is  a program,  CLOSE,  or  PROC  use: 

".JAVSTEXT  <name>  COMPUTE  (^COMPOOL  name>)" 

The  parenthetical  name  informs  JAVS  that  one  or  more  COMPOOLs  are 
referenced,  although  the  COMPOOL  name  is  not  checked  for  validity. 

If  the  START-TERM  is  a COMPOOL  use: 

".JAVSTEXT  <name>  PRESET" 

See  page  3-5  in  the  User's  Guide  and  page  1-7  in  the  Reference  Manual 
for  examples. 

b-  If  JAVS  computation  directives  (ASSERT,  EXPECT,  TRACE,  OFFTRACE)  are 
to  be  used,  insert  them  into  the  source  code  following  normal  JOCIT 
programming  rules  for  placement  and  expression  syntax.  See  Sec.  1.5 
in  the  Reference  Manual  for  description  of  these  directives. 

Create  files 

a.  Complete  JAVS  processing  of  the  source  code  will  require  creation  of 
the  following  files: 


File  code 

Name 

TyPe 

Contents 

01,02 

LIBNEW 

LIBOLD 

Random 

JAVS  data  base  library 

07 

LPUNCH 

Sequential 

Instrumented  source 

08 

AUDIT 

Sequential 

Execution  Trace 

See  page  E-2  of  the  User's  Guide  for  size  estimations  of  these  files. 

b.  Additional  files  which  the  user  may  wish  to  use  are  the  sequential 
C*  file  containing  the  instrumented  object  code  (see  page  D-6, 

User's  Guide)  and  a random  access  h*  file  containing  the  user's 
program  with  instrumented  code. 
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3. 


Perform  syntax  and  structural  analyses 


a.  Execute  the  job  stream  on  page  D-2,  User's  Guide  (or  one  which 
employs  BASIC  and  STRUCTURAL  keywords;  see  Sec.  5 of  the  Reference 
Manual  under  these  keyword  headings). 

b.  Check  JAVS  output  for  any  errors.  The  complete  list  of  errors  is  in 
Appendix  B of  the  Reference  Manual. 

c.  If  necessary,  modify  source  and  reprocess  this  step. 

4.  Obtain  JAVS  documentation  reports 

• Execute  the  job  stream  on  page  D-3,  User's  Guide  or 

• Use  any  of  the  PRINT,  ASSIST  and  DEPENDENCE  commands  to  produce  the 
desired  documentation  reports.  See  Sec.  5 of  the  Reference  Manual 
under  the  appropriate  keyword  headings  for  sample  commands  and 
output . 

5.  Instrument  the  source  code 

a.  For  each  START-TERM  (JAVSTEXT)  execute  the  job  stream  on  page  D-4, 
User's  Guide. 

b.  The  PROBI  commands  direct  JAVS  to  insert  calls  to  the  PROBI  data 
collection  routine  to  initiate  and  terminate  test  cases  at  specified 
statements  in  the  source  code  (statement  numbers  appear  in  the  JAVS 
module  listings).  See  Sects.  5.3  and  6,  User's  Guide  and  page  2-15, 
Reference  Manual  for  PROBI  description.  The  test  case  initiation 
and  termination  PROBI  calls  can  be  inserted  manually  (e.g.,  under 
the  GCOS  EDIT  system)  in  the  Instrumented  or  uninstrumented  source 
code,  or  they  can  be  inserted  at  the  direction  of  the  PROBI  command. 

See  page  2-17,  Reference  Manual  for  a sample  listing  of  probed  code. 

6.  Compile  the  instrumented  source  text 

Use  the  job  stream  on  page  D-6,  User's  Guide,  supplying  any  COMPOOLs 
(in  addition  to  the  JAVS  PRPOOL)  required  for  compilation. 

7.  Load,  execute  and  analyze  program  coverage 

a.  Use  the  job  stream  on  page  D-7,  User's  Guide  as  a basis  for  determining 
the  control  cards  needed  for  executing  and  analyzing  the  program. 
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b.  The  Job  control  cards  required  for  loading  and  executing 

the  program  differ  from  the  user's  normal  sequence  as  follows: 

(1)  The  JAVS  data  collection  routines  must  be  loaded 
(JPROBESX) . If  the  user's  program  is  in  overlay  form, 
load  JPROBESX  in  the  main  link. 

(2)  Load  the  instrumented  object  code  instead  of  the  original 
object  code  (in  the  appropriate  link,  if  overlaid). 

(3)  Supply  the  AUDIT  file  (file  code  08)  for  the  execution 
trace  results. 

c.  The  JAVS  post-test  analysis  (following  user  files  and  data)  control 
cards  include  the  AUDIT  file  (written  during  execution)  and  the  JAVS 
data  base  library  (LIBOLD  on  file  code  01). 

Figure  G.l  shows  the  typical  flow  of  operations  in  using  JAVS.  JAVS 
commands  and  the  data  base  library  are  used  in  all  activities  except  the 
compilation.  The  files  used  in  the  figure  are  the  library  (02,01),  LPUNCH 
(07),  object  (C*),  and  AUDIT  (08). 
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ABSTRACT 


The  JOVIAL  Automated  Verification  System  (JAVS)  is  a control-path 
testing  tool  which  analyzes  source  programs  written  in  the  J3  dialect  of 
the  JOVIAL  language.  From  the  user's  viewpoint,  JAVS  consists  of  a sequence 
of  processing  steps  which  (1)  builds  a database  containing  syntactical  and 
structural  information  about  his  JOVIAL  source  text,  (2)  prepares  documenta- 
tion reports  describing  inter-  and  intra-module  characteristics  of  the  source 
code,  (3)  measures  control-path  coverage  during  program  execution,  and  (4) 
assists  in  pinpointing  untested  source  code  and  preparing  additional  test 
data. 


The  purpose  of  this  document  is  to  describe  in  detail  JAVS  processing 
and  each  of  the  JAVS  commands.  The  organization  of  the  Reference  Manual 
follows  a top-down  approach.  Starting  with  a system  level  description  in  the 
first  section;  each  subsequent  section  describes  a subset  of  the  total  system 
in  detail. 


PREFACE 


This  Reference  Manual  supersedes  the  -1AVS  Reference  Manual,  dated 
November  1976.  Change  bars  in  the  page  margins  indicate  additions  and 
changes  to  the  1976  manual;  asterisks  denote  deletions. 


I 


LIST  OF  JAVS  RETORTS 


• Revised  Methodology  for  Comprehensive  Software  Testing.  This  report  de- 
scribes the  methodology  which  underlies  and  is  supported  by  JAVS.  The  method- 
ology is  tailored  to  be  largely  independent  of  implementation  and  language. 

The  discussion  in  the  text  is  intended  to  he  intuitive  and  demonstrative.  Some 
of  the  methodology  is  based  upon  the  experience  of  using  JAVS  to  test  a large 
information  management  system.  A long-term  growth  path  for  automated  verifica- 
tion systems  that  supports  the  methodology  is  described. 

• JAVS  Technical  Report:  Vol . 1,  User's  Guide.  This  report  is  an  intro- 
duction to  using  JAVS  in  the  testing  process.  iLs  primary  purpose  is  to  acquaint 
the  user  with  the  innate  potential  of  JAVS  to  aid  in  the  program  testing  pro- 
cess so  that  an  efficient  approach  to  program  verification  can  be  undertaken. 

Only  the  basic  principles  by  which  JAVS  provides  this  assistance  are  discussed. 
These  give  the  user  a level  of  understanding  necessary  to  see  the  utility  of 

the  system.  The  material  on  JAVS  processing  in  the  report  is  presented  in  the 
order  normally  followed  by  the  beginning  JAVS  user.  Adequate  testing  can  be 
achieved  using  JAVS  macro  commands  and  the  job  streams  presented  in  this  guide. 
The  Appendices  include  a summary  of  all  JAVS  commands  and  a description  of  JAVS 
operation  at  RADC  with  both  sample  command  sets  and  sample  job  control  state- 
ments . 

• JAVS  Technical  Report:  Vol.  2,  Reference  Manual.  This  report  describes 
in  detail  JAVS  processing  and  each  of  the  JAVS  commands.  The  Reference  Manual 
is  intended  to  be  used  along  with  the  User's  Guide  which  contains  the  machine- 
dependent  information  such  as  job  control  cards  and  file  allocation.  Through- 
out the  Reference  Manual,  modules  from  a sample  J°V1AL  program  are  used  in 

the  examples.  F.ach  JAVS  command  is  explained  in  detail,  and  a sample  of  each 
report  produced  by  JAVS  is  included  with  the  appropriate  command.  The  report 
is  organized  into  two  major  parts:  the  first  four  sections  describing  the  JAVS 
system  and  the  fifth  section  'containing  the  description  of  each  JAVS  command  in 
alphabetical  order. 

The  Appendices  include  a complete  listing  of  all  error  messages  directly 
produced  by  JAVS  processing. 

• JAVS  Computer  Program  Documentation:  Vol.  1,  System  Design  and  Implemen- 
tation ■ This  report  contains  a description  of  JAVS  software  design,  the  organi- 
zation and  contents  of  the  JAVS  data  base,  and  a description  of  the  software 
for  each  JAVS  component:  its  function,  each  of  the  modules  in  the  component, 

and  the  global  data  structures  used  by  the  component.  The  report  is  intended 
primarily  as  an  informal  reference  for  use  in  JAVS  software  maintenance  as  a 
companion  to  the  Software  Analysis  reports  described  below.  Included  in  the 
appendices  are  the  templates  for  probe  code  inserted  by  instrumentation  pro- 
cessing for  both  structural  and  directive  instrumentation  and  an  alphabetical 
list  of  all  modules  in  the  system  (including  system  routines)  with  the  formal 
parameters  and  data  type  of  each  parameter. 

• JAVS  Computer  Program  Documentation:  Vol.  2,  Software  Analysis.  Th i s 
volume  is  a collection  of  computer  output  produced  by  JAVS  standard  processing 
steps.  The  source  for  each  component  of  the  JAVS  software  has  been  analyzed 


iii 


to  produce  enhanced  source  listings  of  JAVS  with  indentation  and  control  struc- 
ture identification,  inter-module  depencence,  all  module  invocations  with  toimnl 
and  actual  parameters,  module  control  structure,  a cross  reference  of  symbol 
useage,  tree  report  for  each  leading  module,  and  report  showing  size  of  each 
component.  It  is  intended  to  be  used  with  the  System  Design  and  Implementation 
Manual  for  JAVS  software  maintenance.  The  Software  Analysis  reports,  on  file 
at  RADC,  are  an  excellent  example  of  the  use  of  JAVS  for  computer  software 
documentation. 

* • JAVS  Final  Report.  The  final  report  for  the  project  describes  the  design, 

implementation  and  testing  of  the  JAVS  syntax  analyzer.  Background  information 
regarding  all  JAVS  contracts  is  provided  as  well  as  procedures  for  installing 
the  complete  JAVS  software  package.  This  report  contains,  as  appendices, 
the  June  1978  updated  pages  for  the  User’s  Guide  and  Reference  Manual  published 
as  RADC-TR-77-126,  Vols.  1 and  II,  April  1977. 
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J«VS  TEST  CASE 

• ••  MONITOREO  NOLLE*?  I TH  OATA  ID 
•••  MONITORED  HOLLERITH  DATA  ITERU 
•••  MONITORED  HOLLERITH  OATA  I TER2A 

RESULT  6T  4 

•••  MONITORED  HOLLERITH  DATA  ID 

• ••  MONITORED  HOLLERITH  DATA  t TER  1 A 
•••  MONITORED  HOLLERITH  DATA  1 T£  R2 A 

RESULT  GT  4 


* T MO 

■ 300 

■ 1 RR 


■ One 
» 45 

• 14 


Figure  1.4.  Output  from  Execution  of  Sample  Program 
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JAVS  automat  leal ly  separates  a START-TERM  sequence  of  JOVIAL  source 
which  contains  executable  JOVIAL  statements  (i.e.,  not  a COMPOOL)  into  modules 
.01  invof-able  code  (e.g.,  a PROC,  a CLOSE).  Alter  the  source  code  has  been 
instrumented,  it  is  reassembled  into  the  START-TERM  sequence  in  preparation 
lor  compilation  and  Test  Execution.  If  more  than  one  START-TERM  sequence  is 
contained  on  the  library,  it  is  necessary  to  identify  each  sequence  separately 
with  a unique  name.  JAVS  lias  provision  for  naming  a START-TERM  sequence  and 
distinguishing  between  types  of  text  through  the  use  of  a special  form  of 
comment  called  a JAVSTKXT  directive: 


" . JAVSTKXT  name  • ■ type''  [ ( • related-text-list*)][<description>] 


where 


< tvpe> 


■ related-text-list> 


<desc r i p t i on > 


is  the  name  given  to  the  START-TERM  sequence  (name 
must  be  S or  less  characters,  in  which  the  first  b 
characters  must  be  unique  among,  the  JAVSTEXT  names) 

is  COMPUTE  for  an  executable  START-TERM  t ex i ( e . g . , 
a program)  c r PRESET  for  nonexecutable  text  (e.g., 
a COMPOOL) 

is  an  optional  list  of  related  text  names  separated 
bv  onmas  (e.g.,  the  name  of  a COMPOOL  text  used 
during  compilation  with  a program  text) 

is  optional  d riptive  information 


The  JAVSTEXT  directive  should  he  used  with  each  START-TERM  sequence  as  the 
first  line  ot  text  in  the  START-TERM  seuaeme. 


In  the  example  program,  the  JAVSTEXT  directive 
".JAVSTEXT  EXCOMP l PRESET" 

i used  to  inform  Javs  that  a COMPOOL  is  being  processed*  The  JAVSTEXT  direc— 
t ive 

".JAVSTEXT  EXP ROOM  COMPUTE  (EXCOMPI)" 

I 


is  used  to  inform  JAVS  that  an  executable  START-TERM  sequence  which  references 
a COMPOOL  (EXCOMPI.)  is  being  processed.  This  directive  is  required  for  a 
COMPOOL  text,  but  may  be  omitted  for  executable  text. 
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2.3  MODULE  INSTRUMENTATION 


This  step  performs  the  instrumentation  of  modules  which  have  been  pro- 
cessed through  BASIC  and  STRUCTURAL.  The  primary  result  of  this  step  is  a 
set  of  probed  modules  which  can  then  be  compiled  in  instrumented  form  for  use 
in  Text  Execution  (see  Sec.  2.4).  Only  modules  which  ha'°  executable  state- 
ments (e.g.  modules  other  than  COMPOOLS)  are  instrumented.  The  instrumented 
modules  are  logically  identical  to  the  original  source  code.  The  probe  state- 
ments are  saved  on  the  library  along  with  data  generated  by  BASIC  and  STRUC- 
TURAL (e.g.,  the  source  text,  etc.).  INSTRUMENT  processing  is  shown  in  Fig. 
2.5. 


from 

STRUCTURAL 


*FR0M  STRUCTURAL 


Figure  2.5.  INSTRUMENT  Processing 
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There  are  two  types  of  instrumentation  generated  during  INSTRUMENT: 

1-  Structural  Instrumentation.  Software  probes  are  automat ica 1 ly 
inserted  into  the  source  text  at  each  invocation  point,  each 
return  point,  and  each  statement  which  begins  a DD-path.  Each 
probe  includes  a call  to  special  auditing  routines  which  cap- 
ture and  record  information  concerning  flow  of  control  in  the 
executing  module(s). 

J.  JAVS  Directive  Instrumentation.  Software  probes  are  manually 

inserted  in  the  source  text  for  JAVS  directives  (Sec.  1.5)  which 
are  automatically  expended  into  JOVIAL  code  to  monitor  the  re- 
sults of  assignment  and  exchange  statements  during  Test  Execution. 
Each  directive  controls  execution-time  output  which  is  inter- 
spersed with  normal  program  output. 


3 JAVS  CONSTRAINTS 


JAVS  imposes  certain  restrictions  on  the  size  of  the  database  library, 
the  command  language,  and  the  source  text  to  be  analyzed.  Most  of  the  limita- 
tions based  on  size  are  generous  (e.g.,  the  maximum  number  of  nested  IF  state- 
ments is  100).  Some  of  the  limitations,  su -h  as  those  in  the  Test  Execution 
process,  can  be  raised  by  recompiling  parts  of  JAVS.  Some  of  the  restrictions 
are  based  upon  computer  page  dimensions  and  cannot  be  changed. 

A number  of  the  constraints  which  affect  the  incoming  JOVIAL  source  code 
are  founded  in  the  principle  of  analyzing  invokable  modules  separately.  The 
dialects  of  JOVIAL  recognized  by  JAVS  allow  certain  constructs  involving  jumps 
to  global  labels,  invocations  of  externally  declared  switches,  and  TEST  state- 
ments where  the  FOR  variable  is  external  to  the  module.  Some  of  these  con- 
structs require  modification  of  the  JOVIAL  source  code,  and  some  cause  a 
warning  message  to  be  issued  to  make  the  user  aware  of  limitations  in  the  DD- 
path  test  measurement  report  and  execution  tracing. 

The  constraints  are  listed  in  sections  (Sec.  3.2  through  3.8)  appropriate 
to  a particular  JAVS  processing  step.  Universal  constraints  (Sec.  3.1)  affect 
all  of  JAVS  processing.  The  terminology  used  in  describing  the  constraints 
requires  knowledge  of  JOVIAL  and  JAVS.  The  use'-'  should  refer  to  the  JOCIT 
Compiler  Users  Manual ^ for  JOVIAL  terms  and  to  the  index  in  this  manual  for 
direction  to  the  descriptions  and  references  to  JAVS  terms. 
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3.1  UNIVERSAL  CONSTRAINTS 


1.  Maximum  3 continuation  cards  for  any  given  JAVS  command. 

2.  Maximum  24  commas  in  any  given  JAVS  command. 

3.  Maximum  150  modules  selected  for  any  given  JAVS  command  iteration 
loop . 

4.  Maximum  250  word-pairs  in  a statement  block.* 

5.  Maximum  100  statements  on  any  DD-path. 

6.  Maximum  25  internal  data  base  tables  during  any  JAVS  execution. 

7.  100  JAVS  errors  produce  a fatal  error. 

8.  Maximum  250  known  modules  during  any  one  JAVS  execution  (i.e., 
total  modules  in  one  or  both  libraries) . 

9.  In  order  to  change  a previously  made  library,  the  name  specified 

for  an  ALTER  LIBRARY  must  be  the  same  as  when  it  was  a CREATE 

LIBRARY . 

10.  Maximum  150  modules  per  JAVSTEXT. 

11.  Maximum  80  characters  per  card  image  read. 

12.  Maximum  128  characters  per  line  of  output. 

13.  No  analysis  is  performed  on  a DIRECT  code  sequence. 

14.  The  recognized  dialects  of  JOVIAL  include  JOCIT  JOVIAL,  J0VIAL/J3, 
CDC  JOVIAL,  and  Honeywell  JOVIAL.  The  combination  of  these  is 
processed  by  JAVS. 


BASIC  automatically  separates  long  source  statements  into  a sequence  of  state- 
ments. The  first  statement  is  given  the  statement  type  according  to  the 
original  JOVIAL  soiree  statement.  Subsequent  statements  are  of  type  continua- 
tion (CONT) . 
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3.2 


JAVS  BASIC  CONSTRAINTS 


BASIL  orocessing  is  capable  of  handling  quite  large  source  text  files. 
Unusually  large  programs  may  have  to  be  processed  by  several  successive  execu- 
tions of  BASIC,  each  operating  on  a separate  file  of  START-TERM  texts. 

The  following  implementation  constraints  are  the  tu.  ■'ent  ones  which  must 
be  observed  during  BASIC  orocessing: 

L.  Each  module  placed  on  the  same  library  must  have  a unique 
module  name  for  a given  JAVSTEXT  name.  For  this  purpose 
only  the  first  eight  characters  of  any  name  are  used.  The 
tirst  six  characters  should  be  unique  (a  compiler  restriction). 

2.  A PROC  must  contain  at  least  one  executable  statement  (e.g. 

RETURN ) . 

3.  Statement  labels  in  direct  code  are  not  analyzed.  A reference 
to  such  a label  in  JOVIAL  code  is  treated  as  a reference  to  an 
external  undefined  label. 

4.  The  maximum  number  of  nested  modules  is  150. 

5.  The  maximum  number  of  unique  symbols  (names  and  constants) 

is  4096. 

6.  A basic  element  may  not  exceed  500  characters  (does  not  include 
literals) . 

7.  A JOVIAL  symbol  may  not  exceed  4095  characters. 

8.  A comment  if  saved  will  be  truncated  to  the  maximum  JOVIAL 

symbol  length  if  it  exceeds  that  length. 

9.  BASIC  guarantees  that  saved  comments  terminate  with  a double 
prime  (i.e.,  a double  prime  will  be  generated). 

10.  Only  the  first  72  columns  of  source  text  line  are  analyzed. 

11.  C0MP00LS  must  have  a JAVSTEXT  directive  stating  the  PRESET 
type. 

12  A statement  name  following  a TERM  (main  program  only)  will  not 
determine  the  first  executable  statement. 


3-  1 


S.  * .1 AVS  STRUCTURAL  CONSTRAINTS 

, 1.  Control  should  not  i fans  for  from  one  moduli?  to  a label  or 

switch  declared  in  another  module.  Control  transfers  of 
this  tvpe  are  treated  as  RETURNS. 

J.  A TEST  statement  must  not  appear  in  the  range  of  a single  factor 
FOR  statement  sequence. 

3.  Function  calls  with  side  effects  (i.e.,  two  successive  calls  to 

the  function  which  produce  different  results)  are  not  permitted  in 

FOR,  IF,  IFKITH,  and  ORiF  statements. 

¥ 

A.  The  maximum  depth  of  nesting  of  control  or  compound  statements 
(IFKITH,  OR 1 F , IF,  FOR,  BEGIN)  is  100. 

i.  1'he  maximum  number  of  DO-paths  which  can  begin  at  a statement 
is  100. 

h.  l'he  maximum  number  ol  statements  on  a single  DD-path  is  100. 

7.  CLOSE  invocations  which  appear  as  switch  points  in  SWITCH 
declarations  are  treated  as  null  switch  points. 

8.  SWITCH  Invocations  which  appear  as  switch  points  (nested  switches) 
in  SWITCH  declarations  are  treated  as  null  switch  points. 

0 . Invocations  of  externally  declared  switches  are  treated  as 
RETURNS. 

10.  l'he  first  three  factor  FOR  statement  in  a parallel  FOR  is 
assumed  to  he  the  controlling  FOR.  If  there  are  no  three 
factor  FOR  statements  in  the  parallel  FOR,  the  first  FOR  state- 
ment is  chosen  as  the  controlling  FOR  for  the  purpose  of  con- 
structing interstatement  pointers  in  the  JAVS  statement  de- 
scriptor blocks. 

I * 

t 

11.  Cl. OS!  declarations  within  a FOR  statement  may  not  use  a TEST 
statement  to  reference  the  active  FOR  variable. 

! 
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3.4  JAVS  INSTRUMENT  CONSTRAINTS 


1.  The  first  three  factor  FOR  statement  in  a parallel  FOR  is 
assumed  to  be  the  controlling  FOR  and  is  instrumented. 

2.  Invocations  of  externally  declared  switches  are  not  instrumented. 

3.  The  maximum  number  of  nested  IF  statements  is  100. 

4.  Subscript  expressions  in  SWITCH  invocations  are  limited  to  72 
characters . 

5.  Item  names  and  switch  names  are  limited  to  30  characters  in 
length . 

6.  The  maximum  number  of  variables  allowed  in  a single  TRACE 
directive  is  18. 

7.  The  maximum  number  of  variables  in  TRACE  directives  is  limited 
to  999  per  module. 

8.  The  maximum  number  of  nested  IFEITH  and/or  IFEITH/ORIF  statements 
is  100. 

9.  The  maximum  DD-path  number  is  9999. 

10.  The  maximum  length  of  the  TEXT  in  an  ASSERT  directive  is  72 
characters . 

11.  The  functional  modifiers  BIT,  CHAR,  MANT,  NENT,  POS  and  BYTE 
may  not  appear  in  the  numeric  formulas  for  FOR  statements; 
i.e.,  no  side-effects  are  allowed  in  the  initial  value  formula. 

12.  FOR  variables  may  not  appear  in  TRACE  or  EXPECT  directives. 


3.5  JAVS  ASSIST  CONSTRAINTS 


1.  Maximum  of  100  DD-paths  per  reaching  set  path. 

2.  Maximum  of  100  outways  per  decision. 

3.  Maximum  of  1200  DD— paths  per  analyzed  module  for  reaching  set. 

4.  Maximum  of  2400  statements  per  analyzed  module  for  reaching  set. 

5.  Maximum  of  200  statements  in  reaching  set. 

6.  Maximum  100  JAVSTEXTs  specified  for  cross-reference  mapping. 

7.  Maximum  of  125  modules  specified  for  cross-reference  mapping. 


I 


4*  3.  3 Mu  1 t i pi  e Modu  1 e 1 l or.it  i on 

In  many  applications,  tlu*  user  will  want  to  repeat  a command  for  a num- 
ber of  different  modules.  Tlu*  three  forms  of  command  iteration  structure 
.ire  described  below. 

4. 3. 3.1  Selected  Module  Iteration. 

The  following  sequence  selects  a number  of  modules,  by  name,  and  itera- 
tes a block  of  commands  (which  cannot  contain  another  iteration)  once  for 
each  specified  module: 


FOR  MODULE  = <name- 1> , <name-2> , . . . , <name-n> . 
(any  set  of  commands) 

END  FOR. 


<*.3.3.2  ALL-Modules  Iteration  for  Specified  JAVSTEXT  (START-TERM  Text). 

The  following  sequence  selects  each  known  module  within  the  "current 
text"  and  iterates  a block  of  commands  (which  cannot  contain  another  iteration) 
once  for  each  known  module  of  that  text : 


FOR  JAVSTEXT. 

(any  set  of  commands) 
END  FOR. 


4. 3. 3. 3 ALL-Modules  Iteration  for  Library. 

The  following  sequence  selects  each  known  module  on  the  library  and 
iterates  a block  of  commands  (which  cannot  contain  another  iteration)  once 
for  each  known  module: 

FOR  LIBRARY. 

(any  set  of  commands) 

END  FOR. 


4.3.4  Module  Selection  Constraint 


The  maximum  number  of  modules  which  may  be  specified  by  a single  itera- 
tion is  150  (see  Sec.  3). 


4-4 


■4  . *4 


1'ROCESS  OPT  LON  COMMANDS 


Processing  steps  BASIC,  STRUCTURAL,  INSTRUMENT  and  ANALYZER  have  option 
commands  which  deline  the  action  taken  when  the  process  execution  command  is 
given.  The  option  commands  follow  the  START  command  and  precede  the 
appropriate  execution  command  (see  Sec.  4.5). 


s.s.l  BASIC  Option  Commands 

lhe  BASIC  options  are  specified  by  the  following  commands  (with  the 
del. uilt  value  assumed  in  case  the  option  command  is  not  given  prior  to  the 
appearance  ot  the  BASIC  execution  command) : 


BASIC, CARD  IMAGES  - ON/OKI . 


DEFAULT  = ON. 


BAS  1C, COMMENTS  = ON /OFF. 


DEFAULT  = ON. 


BASIC, DEFINES  « ON/OFF. 


DEFAULT  = ON. 


BASIC  options  which  have  been  selected  in  the  command  sequence  remain  in 
el  feet  until  they  are  reset  by  a later  command.  See  Sec.  5 for  a complete 
definition  and  example  of  each  BASIC  option  command. 

Che  user  will  note  that  module  selection  commands  do  not  apple  until 
after  a module  has  been  added  to  a 1 ibrarv  -luring  BASIC  processing  bv  the  BASIC 
verb.  lhe  name  assigned  to  a module  when  it  is  added  to  a 1 Ibrarv  is  the  first 
eight  characters  of  the  program  name,  procedure  name,  or  close  name  of  the 
module.  The  tirst  six  characters  of  the  names  should  be  unique. 

It  is  important  that  the  command  sequence  involving  one  or  more  occur- 
rences ol  the  BASIC  execution  command  be  terminated  with  the  END  command  so  that 
1.1BNEW  is  closed  properly.  The  user  may  employ  the  standard  print  and  punch 
commands  (Sec.  5)  alter  the  BASIC  command  and  after  module  or  JAVSTEXT  specl- 
I i cat  ion  (Sec  . 4 . If  . 

*.  * . SI'RlYfURAl  Option  Command 

The  S l'RUCTDRAL  print  option  is  specilied  bv  t lie  following  command  (with 
tin-  spei  il led  default  value  assumed  in  case  the  command  is  not  given  prior  to 
the  appearance  ot  the  STRUCTURAL  verbf: 


SUMMARY  DEBUG. 


■10 


STRUt'TUKAI  ,1'RINl 


(DEFAULT  - SUMMARY) 


5 JAVS  COMMANDS 

1'his  section  contains  a complete  list  of  JAVS  commands,  in  alphabetical 
order,  along  with  the  JAVS  processing  step  in  which  each  command  is  used. 

'e  t^rm  universal"  indicates  that  the  command  can  be  used  in  any  processing 


Following  the  list 
output  and  command  sets. 


of  commands  is  a description, 
of  each  JAVS  command. 


accompanied  with  sample 


A 

1 he  overlay  version  of  JAVS  allows  all  commands  to  he  "universal." 
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T 


JAVS  COMMANDS  (DEFAULTS  UNDERLINED) 

STEP 

ALTER  LIBRARY  = <libnarae>. 

(Universal ) 

ANALYZER. 

ANALYZER 

ANALYZER, ALL. 

ANALYZER 

ANALYZER, ALL  MODULES. 

ANALYZER 

ANALYZER, CASES  = <number>. 

ANALYZER 

ANALYZER , DDPATHS . 

ANALYZER 

ANALYZER , DDPTRACE . 

ANALYZER 

ANALYZER , FACTOR  = '.percent- increase  > . 

ANALYZER 

ANALYZER, HIT. 

ANALYZER 

ANALYZER .MODLST . 

ANALYZER 

ANALYZER, MODTRACE . 

ANALYZER 

ANALYZER, MODULE  = <name-l> , <name-2> , . . . , <name-n> . 

ANALYZER 

ANAI.Y  ZER , NOTH  I T . 

ANALYZER 

ANALYZER, SUMMARY. 

ANALYZER 

ANALYZER, TIME. 

ANALYZER 

ASSIST, CROSSREF.JAVSTEXT  = <text-name-l> , <text-name-2> , . . . , 

< text-name-n> . 

ASSIST 

ASS  I ST, CROSSREF, LIBRARY. 

ASSIST 

ASSIST, PICTURE. 

ASSIST 

ASSIST, PICTURE! .CONTROL} { .NOSWITCH} . 

ASSIST 

ASSIST , REACHING  SET , <number-tos { , "-nuinber-f  rom'  1 
{ .PICTURE! , ITERATIVE) } . 

ASSIST 

ASS  I ST, STATEMENTS. 

ASSIST 

BASIC. 

BASIC 

BASIC, CARD  IMAGES  = ON/OFF. 

BASIC 

BASIC, COMMENTS  = ON/OFF. 

BASIC 

BASIC, DEFINES  = ON /OFF. 

BASIC 

BUILD  LIBRARY  = <librarv  name1  , 

CREATE  LIBRARY  = <libname>. 

BASIC, 

STRUCTURAL 

(Universal ) 

★ 
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JAVS  COMMANDS  (DEFAULTS  UNDERLINED) 


STE!1 


DEPENDENCE, BANDS. 

DEPENDENCE,  BANDS  = <-number>. 

DEPENDENCE , GROUP , AUXLIB . 

DEPENDENCE , GROUP , I l BRARY . 

DEPENDENCE, GROUP, MODULES  = < name-1 >, <name-2> ,..., <name-n> . 
DEPENDENCE, PRINT, INVOKES. 

DEPENDENCE, SUMMARY. 

DEPENDENCE, TREE. 

DESCRIBE  = ON/OFF. 

DOCUMENT! , JAVSTEXT=<  t ext -name * { ,MODULE=<name-l> ,...}}. 


END. 

END  FOR. 


DEPENDENCE 

DEPENDENCE 

DEPENDENCE 

DEPENDENCE 

DEPENDENCE 

DEPENDENCE 

DEPENDENCE 

DEPENDENCE 

(Universal) 

ASSIST, 

DEPENDENCE, 

(Universal) 

(Universal) 
(Universal ) 


FOR  JAVSTEXT. 

FOR  LIBRARY. 

FOR  MODUI E = <name-l>,<name-2> <name-n>. 


(Universal) 
(Universal ) 
(Universal) 


INSTRUMENT. 

INSTRUMENT, MODE  = INVOCATION/DDPATHS/DIRECTIVES/FULL ■ 
INSTRUMENT, PROBE, DDPATH  = <probe-name> . 

INSTRUMENT, PROBE, MODULE  = <invocation-name> . 

INSTRUMENT, PROBE, TEST  - <test-name>. 

INSTRUMENT, STARTTEST  = <modname> , < textname> , <s tmt . no . > 
{ i<TESNAM> } { ,<TFLAG> } . 

INSTRUMENT, STOPTEST  = <modname> , < tex tname > , 

<stmc.  no.>. 


INSTRUMENT 

INSTRUMENT 

INSTRUMENT 

INSTRUMENT 

INSTRUMENT 

INSTRUMENT 

INSTRUMENT 


JAVSTEXT  = <text-name>. 


(Universal ) 


MERGE. 

MODULE  = <name>. 


(Universal) 
(Universa  ’. ) 


OLD  LIBRARY  = <libname>. 


(Universal ) 


* 
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JAVS  COMMANDS  (DEFAULTS  UNDERLINED) 


STEP 


PRINT , DDP . 

(Universa 1 ) 

PRINT, DDPATHS . 

(Universal ) 

PRINT, DMT. 

(Universal ) 

PR1 NT , JAVSTEXT  = 

text-name- I',  INSTRUMENTED  - ALL. 

(Universal) 

PRINT, JAVSTEXT  = 

text-name'',  INSTRUMENTED  = name-l*, 

(Universa 1 ) 

. . . , vname-n '* . 

PRINT, JAVSTEXT  = 

< text-name > . 

( Universal ) 

PR  I NT, MODULE. 

(Universal) 

PRINT, SB. 

(Universa 1 ) 

PRINT, SDB. 

(Universa 1 ) 

PRINT, SLT. 

(Universal) 

PRINT, STB. 

(Universa 1 ) 

PROBE,  JAVSTEXT  = 

<text-name>{ , MODULE  = <name-l> , . . . ) • 

INSTRUMENT, 

(Universal) 

PROB I , S TARTTEST  = 
, IES NAM  1 { , TFLAG } 

^modname' , < textname** , <s  tmt . no  . > 

INSTRUMENT, 

(Universal) 

PROB I , STOP TEST  = 

<modname>f  < textname>, <stmt . no . > . 

INSTRUMENT , 
(Universal ) 

PUNCH,  JAVSTEXT  =■ 

•'text-name'* . 

(Universal) 

PUNCH, JAVSTEXT  = 

^text-name', INSTRUMENTED  - ALL. 

(Universal ) 

PUNCH , JAVSTEXT  = < text-name> , INSTRUMENTED  = <name-l», 

■ name- 2 > ^name-n' . 

(Universal) 

PUNCH, MODULE. 

(Universal ) 

S 1 AR  r . 

(Startup) 

S IRUC TURAL. 

STRUCTURAL 

■ I'K  IV  TURAL , PRINT 

’ SUMMARY /DEBUG. 

STRUCTURAL 

1ES1', MODULE  = ■ name- 1 * , •-name-2s  , . . . ^name-n'* } . 


ANALYZER, 
(Universa 1 ) 


ALTER  LIBRARY 


<name> . 


ALTER  LIBRARY  = <name> . 


Description 

This  option  specifies  that  LIBh’EW  is  a previously  generated  library  to 
be  modified  during  the  current  run.  L1BNEW  is  used  as  a read/write  library. 

Rule 

The  name  of  LIBNEW  must  be  the  same  one  used  when  it  was  first  created. 

Example  Command  Sets 

(11  ALTER  LIBRARY  = REFMAN . 

START . 

FOR  LIBRARY. 

STRUCTURAL. 

END  FOR. 

END . 

This  command  set  will  modify  the  library  created  by  the  BASIC  processing 
step  and  add  the  STRUCTURAL  data  to  the  library  for  each  module  on  the 
library . 

(2)  ALTER  LIBRARY  = REFONE. 

START. 

BASIC. 

END. 

This  command  set  augments  a previously  built  library  with  the  BASIC  pro- 
cessing of  additional  source  text. 
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ANALYZER. 


ANALYZER. 


Description 

The  ANALYZER  execution  command  causes  processing  of  the  post-test  analy- 
sis. If  no  ANALYZER  report  options  are  present,  no  report  is  produced. 

Rules 

Eor  a single  ANALYZER  command, 

(1)  Either  option  MODTRACE  or  DDPTRACE  can  be  used,  but  not  both. 

(2)  A maximum  of  100  test  cases  is  analyzed. 

(3)  Only  one  ANALYZER  execution  command  can  be  used  per  set  of 
commands . 


Example  Command  Sets 


(1)  OLD  LIBRARY  = REFMAN , 

START. 

ANALYZER, ALL  MODULES . 

ANALYZER, ALL. 

ANALYZER. 

END. 

This  set  of  commands  will  produce  the  SUMMARY,  HIT,  NOTHIT,  TIME, 
PDPATHS,  MODLST,  DDPTRACE  post-test  analysis  reports  for  all  modules  on  the 

library. 

(2)  OLD  LIBRARY  = TRFMAN. 

START . 

ANALYZER, CASES  = 50. 

ANALYZER, MODULE  = EXPROCM, EXMPL1 . 

ANALYZER, SUMMARY. 

ANALYZER, NOTHIT. 

ANALYZER, PDPATHS. 

ANALYZER, DDPTRACE. 

ANALYZER. 

END. 
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BASIC. COMMENTS  = <optlon>. 


BASIC. COMMENTS  = <optlon>. 


Description 


BASIC, COMMENTS  = ON/OFF.  (DEFAULT  = ON.) 


This  command  allows  user  control  over  the  treatment  of  comments  in  tie 
nodule  source  text.  The  default  action  is  to  include  all  comments  in  the 
library.  Comments  may  be  excluded  from  the  statement  text  table  of  all 
modules  by  the  command 


BASIC, COMMENTS  = OFF. 


If  comments  are  included,  more  space  is  required  on  the  library  and  all  subse- 
quent processing  of  the  statement  table  requires  more  computer  time. 


Sample  Command  Set 


CREATE  LIBRARY  = RF.FMAN . 
START. 

BASIC, COMMENTS  = OFF. 
BASIC. 

END. 


r 


BASIC, DEFINES 


<opt ion> . 


BASIC, DEFINES 


<option> . 


Description 


BASIC, DEFINES  = ON/OFF.  (DEFAULT 


This  command  allows  the  user  control  over  BASIC  usage  of  DEFINE  vari- 
ables. The  default  option  is  to  replace  the  occurrence  of  each  DEFINE  vari- 
able with  its  definition  just  as  the  JOVIAL  compiler  does.  Subsequent  BASIC 
processing  utilizes  the  results  of  that  definition  both  in  statement  analysis 
and  in  the  text  stored  for  each  statement  on  the  library.  It  is  essential 
that  the  default  option  be  used  if  the  modules  are  to  be  processed  by  any 
other  JAVS  standard  processing  step. 

Replacement  of  DEFINE  variables  by  their  definition  may  be  suppressed 
with  the  command: 

BASIC, DEFINES  = OFF. 


Text  so  processed  mav  be  written  to  LPITJCH  in  the  structured  (i.e.,  indented) 
format  with  the  command: 

rUNCH , JAVSTEXT  = <-text-name> . 

This  is  useful  in  using  JAVS  to  punch  a copy  of  reformatted  source  text.  To 
get  a reformatted  listing  of  the  source  text,  the  PRINT, JAVSTEXT  command  can 
be  used. 


Bl'ILD  L l BRAKY  . 


BUILD  LIBRARY. 


Description 

This  macro  command  has  two  forms: 

BUILD  LIBRARY.  or 

BUILD  LIBRARY  = <name>. 

In  the  first  command  form,  the  library  name  given  to  LIBNEW  is  TEST.  In  the 
second  form,  the  user  specifies  the  library  name.  Both  command  forms  generate 
the  following  JAVS  standard  commands: 

CREATE  LIBRARY  = <name> . (or  TEST) 

START. 

BASIC, COMMENTS  = ON. 

BASIC. 

FOR  LIBRARY. 

STRUCTURAL. 

END  FOR. 

The  macro  command  processor  generates  the  JAVS  "END"  command  if  it  is  not 
present  as  the  last  command. 

Rules 

(1)  See  BASIC  and  STRUCTURAL  constraints  in  Sec.  3.2  and  3.3. 

(2)  The  library  name  should  be  8 or  less  characters. 

(3)  This  macro  command  should  not  be  used  if  the  source  program  includes 
a COMPOOL  (constraint  2 on  page  3-3). 


Example  Command  Sets 

(1)  BUILD  LIBRARY  = REFMAN. 

DOCUMENT . 

This  command  set  will  create  a new  library,  perform  syntax  and  structural 
analyses  and  produce  a series  of  JAVS  reports  for  all  modules  in  the  JOVIAL 
source  program.  These  reports  are  useful  for  documentation,  maintenance, 
testing  and  retesting  the  source  program. 

(2)  BUILD  LI BRARY . 

PROBE, JAVS TEXT  = EXPROGM. 

PRINT, JAVSTEXT  = EXPROGM, INSTRUMENTED  = ALL. 


Can  be  used  only  with  the  overlay  version  of  JAVS. 
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BUILD  LIBRARY . tCont . ) 


•rhe  n;h;Snl^rnd  SOt  ,Sh?V?  3 miXtUle  of  JAVS  raacr°  and  Standard  commands. 
S .e  u command  will  create  a new  library  called  TEST  and  perform 

Hi  StrUCtUral  analySeS  °n  aU  m°dulcS  111  the  ^VIAL  source  program. 

RiBL  macro  command  will  instrument  JAYSTEXT  EXP ROOM,  using  the  default 

ns  rumen tat  ion  options,  and  write  the  instrumented  text  onto  file  LPUNCH 
Ihe  last  command  will  print  the  instrumented  text. 


DOCUMENT.  DOCUMENT ■ 


Descr iptiun 


This 

macro  command  has 

three  forms: 

(1) 

DOCUMENT. 

(2) 

DOCUMENT, JAVSTEXT 

= < text-name-' . 

(3) 

DOCUMENT, JAVSTEXT 
MODULE  = <name- I > , 

= <text-name>, 

, <name-2> .... <name-n> 

Each  form  o f the  DOCUMENT  macro  command  generates  a series  of  J A V standard 
commands  which  produce  reports  useful  for  program  documentation,  maintenance, 
and  testing. 

The  expansion  of  each  form  of  the  DOCUMENT  macro  command  is  as  tallow-. : 

(1)  ASSIST, CROSSREF, LIBRARY. 

DEPENDENCE , CROUP , LIBRARY . 

DEPENDENCE , GROUP , AUXLIB . 

DEPENDENCE , S UMMARY . 

FOR  LIBRARY. 

PRINT, MODULE. 

DEPENDENCE, BANDS  = 5. 

DEPENDENCE , PRINT , INVOKES . 

END  FOR. 

This  form  (DOCUMENT.)  is  for  documenting  the  entire  library. 

(2)  ASSIST, CROSSREF, LIBRARY. 

DEPENDENCE , GROUP .LIBRARY . 

DEPENDENCE .GROUP .AUXLIB . 

DEPENDENCE , SUMMARY . 

JAVSTEXT  = <text-name>. 

FOR  JAVSTEXT. 

PRINT, MODULE. 

DEPENDENCE, BANDS  = 5. 

DEPENDENCE, PRINT, INVOKES. 

END  FOR. 

This  form  (DOCUMENT .JAVSTEXT  = - tex t-name> . ) Is  for  documenting  module 
interdependencies  for  the  entire  library,  producing  a library-wtdi  cross 
reference  of  symbols,  and  generating  nodule  documentary  reports  tor  < 
t ied  JAVSTEXT. 


-S>'- 


DOCUMF  N 1 . I Coni.) 


(,  |)  ASSISI  .CROSS  KIT,  LIBRARY. 

DEPENDENCE  .llKOl'P,  LIBRARY  . 

DEl’ENDENl T.lIKi'lT.Al'Xl  IB. 

DEPENDENCE  , SUMMARY  . 

JAVSTEXT  “ 'text-iumc'  . 

FOR  MODULE  name-  1 ' , name--'  • ' name-no  • 

PRLN'l , MODULI  . 

DEPENDENCE . BANDS  >. 

END  FOR . 


Hus  form  ( DOL'EMEN  1' , .1  AVSTI’X  f text-name-,  MODEL!'  ' 

produces  the  same  report  as  in  UK  except  that  the  module  report  ■= 
ted  only  lor  the  specified  modules  in  the  'AVSI'I-.M. 


.n't*  gctuM.i 


l’he  macro  command  procossoi  will  generate  the  commands. 

OLD  LIBRARY  = TEST, 
s tar  r . 


If  the  first  JAVS  command  Is  a macro  command  (.keywords  BUILD  LIBRARY, 
KENT,  r).  riie  macro  command  processor  will  generati  t le 

c ommand,  il  it  is  not  present. 


"END" 


Ku  1 es 

11) 


A maximum  o! 


100  iaVSTEXTs  can  be  used  in  a cross  reference  mapping. 


A maximum  ot  100  modules  can  be  used  in  the  CROUP  reports. 

V 1)  a maximum  ot  11  modules  can  be  specified  In  the  second  term  ot  th 
DOCUMENT  macro. 


I A) 


rhe  LXK’EMKN r 1».V . • command  requires  that  syntax  and  structural 
analvses  have  already  been  performed  on  the  entire  llhrarv. 


Exam^>  lc  Command  _Sci  . 
i 1) 


BE  l l.D  LIBRARY. 
DiYt  Ml  N 1 . 


this  command  set  will  create  a new 
doenmentat ion  reports  for  all  modules  on 


1 lb i ary  cal  1 
the  llhrarv. 


;d  VEST  and  produce  JAVS 


U’)  OLD  LIBRARY  « REl'MAN. 

Pi'h\'mi.N  I ,.l  AYS  VEX  1'  E XPROCM .MODULE  EXMP1.1  . EXMPI.2 .EXMPl. 3 . 
for  MODULE  ■ EXMl’l.  I , EXMl’Ll . KXMPI  1. 

PR  I NT,  PDF  A I'HS  . 

END  FOR. 


END.  (Cont.) 


5.  Type  of  module  where 

CMPL  is  a COMPOOL 

PROG  is  a Program 

PROC  is  a Procedure 

CLSM  is  a CLOSE  of  global  scope 

CLSP  is  a CLOSE  of  local  scope 

6.  Scope  of  an  executable  module  where 

EXT  is  a program  or  an  external  procedure 

INT  is  an  internal  procedure  (i.e.,  within  a program  or 
external  procedure) 

CLBL  is  a CLOSE  within  a program  or  external  procedure 
LOCL  is  a CLOSE  within  an  internal  procedure 

7.  Number  of  lines  of  probed  text  inserted  in  the  module  by  INSTRUMENT 

8.  Number  of  statements  in  the  module 

9.  Number  of  executable  statements 

10.  The  statement  number  of  the  first  executable  statement 

11.  Word  pairs  which  measure  the  amount  of  library  space  occupied  by 
the  source  text 

12.  Number  of  tokens  in  the  module 

13.  Number  of  symbols  defined  in  module 

14.  Number  of  symbols  referenced  in  module 

I 

The  remainder  of  the  statistics  are  more  applicable  to  users  who  wish  to 
follow  a testing  strategy  of  analyzing  the  complexity  of  their  codes  and 
applying  testcases  to  more  comprehensively  exercise  those  modules  which  exhi- 
bit a greater  tendency  to  be  error  prone.  These  statistics  are  listed  below: 


FNR.  (Cont . ) 


15.  Number  of  other  modules  invoked  by  module 

lb.  Number  of  PD-paths 

17.  Number  of  DD-path/statement  block  entries 

18.  Number  of  formal  input  parameters 

19.  Number  of  formal  output  parameters  (-1  if  the  module  is  a 

funct ion) 

20.  VES  if  DIRECT  code  is  present  in  module;  NO  otherwise 

21.  Statement-based  complexity  is  a summation  of  the  complexity  of  all 
statements  in  the  module. + 

22.  DD-path  based  complexity  is  a summation  of  the  complexity  of  all 
PP-paths  in  the  module.  This  is  used  as  an  indicator  of  the 
structural  complexity  of  the  module. 

These  statistics  can  he  used  by  the  tester  to  develop  a rational 
approach  to  program  verification  of  modules  which  have  the  greatest  tendency 
toward  error  (i.e.,  those  which  are  most  complex). 

The  Library  Information  report  shown  in  the  sample  output  includes  the 
name  for  each  library,  the  type  of  access,  the  date  created,  the  total  size 
and  other  useful  information. 


These  items  are  provided  for  future  extensions  to  JAVS  and  are  not  presently 
computed . 


S-(v, 


PRINT, STB. 


PRINT, STB. 


Description 

This  command  produces  a listing  of  the  detailed,  internal  symbol  table 
(STB)  descriptors  for  each  symbol  defined  in  the  current  module.  Normally  the 
list  includes  only  those  symbols  essential  to  structural  analysis  of  the 
module.  A BASIC  processing  option  causes  all  symbols  defined  in  the  module  to 
be  entered  in  the  STB  (see  BASIC  SYMBOLS  ■ ON).  The  properties  of  each  symbol 
and  pointers  to  other  JAVS-internal  tables  are  included.  Thi6  output  is  in- 
tended for  JAVS  system  maintenance  only. 

Sample  Output 

$T«BOL  TABLE  LIS'INO 

MODULE  1 >•  J«VSTE«!  «E  APROOM  >.  PARENT  MODULE  4 E APROGM  > 


NO. 

SrMROL 

1 ? 

3 

4 

5 6 

7 

• 

9 

10 

11  It 

13 

14 

15 

10 

17 

16 

19 

to 

?? 

? 3 1 4 1 7 

?9  30 

I 

PJC* 

t LOCI 

INS* 

4 

0 

• 

• 

0 

0 

0 

0 

0 

0 

0 

? 7 

C«MPLl 

1 J 

? 

{ A Rf  l I 

1 lOCL 

LA3L 

4 

1* 

• 

• 

0 

0 

0 

0 

0 

0 

0 

30 

l**PL  1 

I* 

1 

LAHf It 

I LOCI 

L*3L 

4 

15 

• 

0 

0 

0 

0 

0 

0 

0 

0 

?9 

l*MPl  1 

15 

Example  Command  Set 

OLD  LIBRARY  = REFMAN. 
START . 

FOR  LIBRARY. 

PRINT, STB. 

END  FOR. 

END. 
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PROBE. 


PROBE. 


De  si r ipt ion 

The  PROBE  macro  command  has  two  forms: 

(1)  PROBE , JAVS TEXT  = "text  name>. 

PROBE, JAVSTEXT  = "text  name'',  MODULE  = <name-l>,<name-2>, . . . , 

< name-n> . 

Each  form  of  the  PROBE  macro  command  generates  a series  of  JAVS  standard 
commands  which  cause  instrumentation  to  be  performed. 

I In  expansion  ot  each  torm  oi  the  PROBE  macro  into  JAVS  standard  commands 
is  as  I o 1 lows : 


JAVSTEXT  = < text-name'* . 

FOR  JAVSTEXT. 

INSTRUMENT. 

END  FOR. 

PUNCH  .JAVSTEXT  = <text  name'' , INSTRUMENTED  = ALL. 

This  torm  (PROBE, JAVSTEXT  = <text  name"*.)  should  be  used  for  instrumen- 
tation ot  a specified  JAVSTEXT. 

(2)  JAVSTEXT  = i text  name>. 

FOR  MODULE  = <name-l> , . . . , <name-n> . 

INSTRUMENT. 

END  FOR. 

PUNCH, JAVSTEXT  = <text  name" , INSTRUMENTED  = <name-l> <name-n". 

This  torm  (PROBE , JAVSTEXT  =>  "text  name",  MODULE  = <name-l> . . . . ) should 
be  used  it  only  selected  modules  of  a given  JAVSTEXT  are  to  be  instrumented. 


F 

ii 


PROBE.  (Cont.) 


With  all  forms  of  the  PROBE  macro,  the  user  can  specify  automatic  .» 
sertion  of  the  PROBI  (test  case  initiation  and  test  termination  data  collec- 
tion routine)  calls  by  preceding  the  PROBE  command  with: 

PROBI .STARTTEST  - <modname> , < tex tname> , <s tmt . no. > , { , TESNAM ) { , TFLAG } . 

PROBI , STOPTEST  = <modname> ,<textname> ,<stmt.  no . > . 

These  commands  are  described  in  Sec.  5 under  their  own  heading.  They 
perform  the  same  function  as  the  INSTRUMENT , STARTTEST  and  INSTRUMENT , STOPTEST 
commands.  The  existence  of  the  PROBI  commands  aids  the  macro  command  processor 
which  will  insert  the  STARTTEST  and  STOPTEST  commands  in  the  generated  series 
of  commands. 


Note 


The  macro  command  processor  will  generate  the  commands: 

OLD  LIBRARY  =■  TEST. 

START. 

if  the  first  JAVS  command  Is  a macro  comma nd  (keywords  BUILD  LIBRARY , DOCUMENT , 
PROBE, TEST).  The  macro  command  processor  will  generate  the  "END"  command,  if 
it  is  not  present. 


Rules 


(1) 

See  INSTRUMENT  constraints  in  Sec.  3.4 

• 

(2) 

Maximum  of  150  modules  selected  in  the 
PROBE  macro  command. 

first 

form 

of 

the 

(3) 

Maximum  of  23  modules  selected  in  the 
macro  command. 

second 

form 

of 

the  PROBE 

(9) 

Use  PROBI  (not  INSTRUMENT , STARTTEST  and  STOPTEST) 
the  PROBE  macro. 

commands  with 

Example  Command  Sets 

(1)  BUILD  LIBRARY. 

PROBE, JAVSTEXT  - EXPROGM. 

DOCUMENT. 

PRINT, JAVSTEXT  = EXPROGM, INSTRUMENTED  = ALL. 

This  command  set  will  create  a new  library,  perform  syntax  and  structural 
analyses,  instrument  the  JAVSTEXT  EXPROGM,  document  an  entire  library,  and 
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print  the  instrumented"  JavStExI1  so  that  the  user  can  see  where  the  PROBI  calls 
should  be  manually  placed. 

(1)  OLD  UBRARV  = TEST. 

START. 

PROBI, STAKTTEST  = EXPROGM, EXP ROOM, 0. 

P ROB 1 , S TARTTES T - E XMP L 1 , EXP ROOM , 9 . 

PROBI, STOP TEST  - EXP ROOM, EXPROGM, 0. 

pROBE, JAVS TEXT  = EXPROGM. 

This  command  set  will  instrument  JAVSTEXT  EXPROGM  in  the  existing  lib- 
rary TEST.  In  addition,  the  PROBI  calls  will  be  automatically  inserted.  The 
first  P ROB l , S TARTTES T command  will  cause  an  invocation  to  PROBI  to  be  inserted 
prior  to  the  first  executable  statement  in  module  EXPROGM.  The  second  PROBI, 

S TARTTEST  command  will  cause  a PROBI  invocation  to  be  placed  immediately  before 
statement  9 of  nodule  EXMPLl.  These  two  PROBI  invocations  will  initiate  a 
new  u t case  whenever  the  PROBI  call  is  executed. 

The  PROBI , STOPTEST  command  will  cause  the  test  termination  PROBI  invoca- 
tion to  be  placed  at  all  exits  from  module  EXPROGM.  The  PROBE  macro  command 
will  instrument  the  JAVSTEXT  EXPROGM  and  write  the  instrumented  text,  including 
the  invocations  to  PROBI,  onto  file  LPUNCH. 

Mote  that  the  library  definition  and  startup  commands  are  included  in 
th is  example.  Even  though  the  default  library  name  is  specified,  these  com- 
munis are  required  because  PROBI  is  not  a macro  command. 


PROBI  ,STARTTEST  ° <options>. 


PROBI , STARTTEST  = <optlons>. 


Description 

This  command  performs  the  same  function  as: 

INSTRUMENT, STARTTEST  = <options>. 

Refer  to  this  heading  for  the  commind  description  and  example  command 

sets . 


Rules 

(1)  This  command  is  to  be  used  only  in  conjunction  with  the  PROBE  macro 
command  and  must  precede  the  PROBE  command. 

(2)  Maximum  of  10  PROBI, STARTTEST  commands  with  a single  PROBE  macro 
command . 

(3)  Command  options  must  be  given  in  the  order  shown  in  the  command 
description. 

(4)  Modules  specified  in  PROBI, STARTTEST  commands  must  be  selected  by 
the  PROBE  macro  command. 

(5)  Library  identification  and  startup  commands  must  be  included  in  the 
command  set. 


. 


««  ••  *c> 


Dexcr  ip t ion 


PROBI , STOPTEST  = <options>. 


Ihis  command  performs  the  same  function  as: 

INSTRUMENT, STOPTEST  = <options>. 

Refer  to  this  heading  for  the  command  description  and  example  command  sets. 


Rules 

(1)  This  command  is  to  be  used  only  in  conjunction  with  the  PROBE 
macro  command  and  must  precede  the  PROBE  command. 

(2)  Only  one  PROBI , STOPTEST  command  with  a single  PROBE  macro  command. 

(3)  Command  options  must  be  given  in  the  order  shown  in  the  command 
description. 

(4)  The  module  specified  in  the  PROBI , STOPTEST  command  must  be  selected 
by  the  PROBE  macro  command. 

(5)  Library  identification  and  startup  commands  must  be  included  in  the 
command  set. 
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TEST. 


TEST. 


Description 

The  TEST  macro  command  has  two  forms: 

(1)  TEST. 

(.2)  TEST, MODULE  =>  <name-l>  , <name-2>  , . . . , <name-n> . 

The  TEST  macro  command  generates  a series  of  JAVS  ANALYZER  commands  for  post- 
test analysis. 

The  expansion  of  the  two  forms  of  TEST  is  as  follows: 

(1)  ANALYZER, ALL  MODULES. 

ANALYZER, SUMMARY. 

ANALYZER, NOTH IT. 

ANALY ZER , MODTRACE . 

ANALYZER . 

(2)  ANALYZER, MODULE  = <name-l> , . . . , <name-n> . 

ANALYZER, SUMMARY. 

ANALYZER, NOTHIT. 

ANALYZER, MODTRACE. 

ANALYZER. 

Additional  pose-test  analysis  reports  can  be  produced  by  preceding  the 
TEST  macro  with  ANALYZER  process  option  commands.  In  this  case,  library  iden- 
tification and  startup  commands  must  be  included  in  the  command  set. 

Note 


The  macro  ^.command  processor  will  generate  the  commands: 

OLD  LIBRARY  = TEST. 

START. 

it  the  first  JAVS  command  is  a macro  command  (keywords  BUILD  LIBRARY .DOCUMENT, 
PROBE, TEST) . The  macro  command  processor  will  generate  the  "END"  command,  if 
it  is  not  present. 

Ru  les 

(1)  The  ANALYZER , DDPTRACE  standard  command  cannot  be  used  in  conjunction 
with  the  TEST  macro. 


iL 
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(2)  ANALYZER  option  commands  must  precede  the  TEST  macro,  if  they 
are  used. 

(3)  See  ANALYZER  constraints  in  Sec.  3.8. 


Example  Command  Sets 

(1)  TEST. 

FOR  LIBRARY. 

PRINT, DDP . 

END  FOR. 

(2)  OLD  LIBRARY  « REFMAN. 

START. 

ANALYZER, MODLST. 

ANALYZER, DDP ATHS . 

TEST, MODULE  - EXPROGM, EXMPL1 . 
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BASIC  ERROR  MESSACES 


B . 2 


The  error  messages  resulting  from  BASIC  source  code  analysis  are: 


Error 
N ■ 

1 

2 

3 

4 

5 

6 

7 

8 
9 

10 

11 


12 


Explanation 

Basic  element  contains  too  l.  any  characters.  Element  truncated 
in  saved  text.  Resubmit  with  corrected  text. 

k 

Illegal  interval  text  character.  System  error. 

k 

Illegal  external  text  character.  System  error. 

Nested  DEFINE  reference.  Reference  partially  expanded  Re- 
submit with  nested  DEFINE  reference  corrected. 

JOVIAL  symbol  too  long.  Symbol  truncated  in  saved  text. 
Resubmit  with  corrected  text. 

Too  many  symbols  (names  and  constants)  in  text.  Fatal  error. 
Resubmit  with  text  partitioned  into  more  START-TERM  sequences. 

Module  nesting  exceeds  limit.  Change  module  nesting  structure. 

Too  many  ENDs . Resubmit  with  corrected  text. 

★ 

Loop  in  basic  element  analysis.  System  error. 

k 

Loop  in  internal  text  character  analysis.  System  error. 

k 

Loop  in  JOVIAL  element  analysis.  System  error. 

* 

Loop  in  external  character  analysis.  System  error. 


k 

System  errors  should  be  reported  with  output  listing  card  images  processe 
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I NI'  FOR. 


r,_,,0 


Error 

Message 

Nested  switch  call  treated  as  fall 
through  case 

Never  found  PROC  statement 

Pointer  LQ  0 

Possible  infinite  loop  detected 

Stack  overflow 

Stack  underflow 
Switch  name  missing 

Test  stack  overflow 

Too  many  paths  begin  at  statement 


Too  many  statements  on  DD-path 


Undefined  GOTO 


Corrective 

Action 

Replace  switch  ■'^vocation  in  switch 
declaration  by  a label  and  rerun  BASIC 
and  STRUCTURAL 

JOVIAL  procedure  must  contain  PROC 
statement.  Rerun  BASIC  and  STRUCTURAL 

Rerun  STRUCTURAL 

Rewrite  module  to  remove  infinite  loop. 
Rerun  BASIC  and  STRUCTURAL 

Increase  the  stack  size  by  recompiling 

STRUCTURAL.  Rerun  STRUCTURAL. 

Rerun  BASIC  and  STRUCTURAL 

Check  SWITCH  syntax  and  rerun  BASIC  and 
STRUCTURAL 

Increase  the  size  of  the  test  stack  by 
recompiling  STRUCTURAL.  Rerun 
STRUCTURAL 

Increase  the  size  of  the  DD-path  queue 
by  recompiling  STRUCTURAL  and  rerun 
STRUCTURAL.  Or  modify  module  to  have 
fewer  than  100  switch  points  in  the 
switch  declaration  and  rerun  BASIC  and 
STRUCTURAL. 

Increase  the  size  of  the  DD-path  state- 
ment list  by  recompiling  STRUCTURAL  and 
rerun  STRUCTURAL.  Or  modify  module 
to  contain  a dummy  decision  to  reduce 
the  number  of  statements  on  a DD-path 
to  fewer  than  100  and  rerun  BASIC  and 
STRUCTURAL. 

Check  location  of  label  referenced  in 
GOTO.  Rerun  BASIC  and  STRUCTURAL 
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INSTRUMENT  ERROR  MESSAGES 


Error 

Message 

Bad  module  number 

BEGIN-END  block  contains  no 
statements 

Could  not  match  parentheses 

Delimiter  stack  overflow 

Directive  not  recognized 

External  switch  call  not 
instrumented 

GOTO  label  not  found 

Input  string  too  long — truncated 
from  head 

Invalid  statement  type  in  chain 

Invalid  switch  type 

Last  statement  in  module  is  not 
TERM  or  END 

No  DD-path  for  statement 

Number  of  switch  labels  <“  0 

ORIF  statement  number  not  on  false 
branch  stack 

Pointer  out  of  range 


Correct i ve 
Action 

Specify  a module  number  within  the 
library.  Rerun  INSTRUMENT 

Informative  message 


Check  syntax  of  statement.  Rerun 
BASIC,  STRUCTURAL , and  INSTRUMENT 

Increase  the  size  of  the  delimiter 
stack  by  recompiling  INSTRUMENT.  Re- 
run INSTRUMENT. 

Check  syntax  of  directive.  Rerun 
BASIC,  STRUCTURAL  and  INSTRUMENT 

Declare  switch  in  module.  Rerun  BASIC, 
STRUCTURAL,  and  INSTRUMENT 

Check  svntax  of  GOTO  statement . Rerun 
BASIC,  STRUCTURAL,  and  INSTRUMENT 

Change  size  of  internal  buffers  by 
recompiling  INSTRUMENT.  Rerun 
INSTRUMENT 

Check  syntax  of  IFEITH  statement.  Re- 
run BASIC,  STRUCTURAL , and  INSTRUMENT 

Check  svntax  of  switch  declaration. 
Rerun  BASIC,  STRUCTURAL , and  INSTRUMENT 

Add  a TERM  or  END  statement  to  the 
module  and  rerun  BASIC,  STRUCTURAI  and 
INSTRUMENT 

Rerun  STRUCTURAL  and  INSTRUMENT 
Rerun  STRUCTURAL  and  INSTRUMENT 
Rerun  INSTRUMENT 


Rerun  STRUCTURAI.  and  INSTRUMENT 
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MISSION 

of 

Rome  Air  Development  Center 


RADC  plans  and  conducts  research,  exploratory  and  advanced 
development  programs  In  command,  control,  and  communications 
(C3)  activities,  and  in  the  C3  areas  of  information  sciences 
and  intelligence.  The  principal  technical  mission  areas 
are  communications,  electromagnetic  guidance  and  control, 
surveillance  of  ground  and  aerospace  objects,  intelligence 
data  collection  and  handling,  information  system  technology, 
ionospheric  propagation,  solid  state  sciences,  microwave 
physics  and  electronic  reliability,  maintainability  and 
compatibility . 


